Flexible buffer size adjustment in graphics processors

Abstract

Flexible buffer size adjustment in a graphics processor is described. Enhanced data buffer control in a data system is presented herein. In one example, a method of handling data buffer resources in a graphics processor includes establishing a pool of available memory pages tracked by a memory pointer for use in a swellable data structure. The method includes, in response to a request of at least a shader unit of the graphics processor for a space in the smeltable data structure for writing shader data, providing at least a write pointer to the shader unit that points to a location of a memory page in the smeltable data structure in accordance with a data size indicated in the request. The method includes allocating at least one further memory page from the pool of available memory pages for inclusion in the swellable data structure in response to exceeding a threshold fullness of the swellable data structure.

Description

[0001] This invention patent application is a divisional application of the invention patent application with international application number PCT / US2018 / 035519, international application date June 1, 2018, application number 201880050739.X entering the Chinese national phase, and name “Flexible buffer size adjustment in graphics processor”. background

[0003] Computing systems such as personal computers, portable computing platforms, gaming systems, and servers may include graphics processors as well as main / central processing units. These graphics processors, sometimes referred to as graphics processing units (GPUs), may be integrated into the central processing unit, or may be discretely provided on separate plug-in cards in other configurations. User applications, operating systems, video games, or other software elements may interface with the GPU using various application programming interfaces (APIs) that allow standardized software / logic interfaces between software elements and various GPU hardware elements.

[0004] Most GPUs may have a specialized role for rendering both two-dimensional (2D) and three-dimensional (3D) graphics data for display, such as graphics data from an operating system, productivity applications, entertainment media, scientific analysis, gaming software, or other graphics data sources. GPUs may also be employed in general processing environments, such as artificial intelligence, machine learning, neural networks, statistical analysis, and cryptocurrency mining. Within the GPU, various internal stages may process the graphics data into rendered images for display on a suitable display device. In many GPUs, these internal stages include a graphics pipeline that may acquire a representation of a scene or user interface and render it into an image for output to various display devices. Included in these GPU stages are shader stages and other stages and functions that provide graphical details, surface texture mapping, color, shading, or other elements of various parts of the rendered image.

[0005] Overview

[0006] The present invention discloses an implementation of multiple growable data queues and stack structures for use in a highly parallelized processing environment. In one example, a method for handling data buffer resources in a graphics processor includes establishing a pool of available memory pages tracked by a memory pointer for use in a growable data structure. The method includes, in response to a request by at least a shader unit of the graphics processor for space in the growable data structure for writing shader data, providing to the shader unit at least a write pointer to a location of a memory page in the growable data structure based on a data size indicated in the request. The method includes, in response to exceeding a threshold fullness of the growable data structure, allocating at least one further memory page from the pool of available memory pages for inclusion in the growable data structure.

[0007] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. It should be understood that this Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Many aspects of the present disclosure may be better understood with reference to the following drawings. Although several implementations are described in conjunction with these drawings, the present disclosure is not limited to the implementations disclosed herein. On the contrary, it is intended to cover all alternatives, modifications and equivalents.

[0010] Figure 1 A data processing environment in one implementation is illustrated.

[0011] Figure 2 A method of operating a data buffer handling system in one implementation is illustrated.

[0012] Figure 3 A data buffer handling system and process in one implementation is illustrated.

[0013] Figure 4 A data buffer handling system and process in one implementation is illustrated.

[0014] Figure 5 An example tracking structure in an implementation is illustrated.

[0015] Figure 6 An example growable data structure in one implementation is illustrated. Detailed Description

[0017] A graphics processing unit (GPU) includes various internal hardware components, such as processing stages, memory elements, and other pipelined processing elements. The GPU and associated supporting software can render two-dimensional (2D) and three-dimensional (3D) graphics. In some examples, the GPU applies shading and texture data to target objects in a 3D space rendered to a user. Shading data provides varying brightness, darkness, and color in rendering, while texture data provides surface details, surface graphics, textures, or other surface features to represent objects with desired surface details. The texture and shading process may be processor intensive and require a large amount of memory to complete. It is expected that user content (such as video game content) rendered by the GPU will continue to grow in complexity over time, but it is expected that graphics hardware constraints such as bandwidth and memory capacity will not grow at a similar rate. The technology discussed herein provides an improved shader and associated data buffer element for the GPU. The enhanced buffer structure herein allows the buffer to be flexibly resized in response to current graphics processing needs, provides more efficient use of memory resources, and batches and sorts data operations for shading operations in the graphics processor.

[0018] Developers of graphics-centric software (such as video game developers or other programmers) often encounter the following scenario: one of the shaders generates data and stores the data in a data structure, and then another shader uses the data from the data structure. Some examples use data structures in which data can be generated and used simultaneously. Further examples use a first-in, first-out (FIFO) buffer arrangement, which requires multiple FIFOs, where any amount of data is stored in each FIFO, but the amount of data to be stored in each FIFO is unknown in advance. Each example herein can provide an alarm that can be generated when new data is added to the FIFO so that the associated scheduling element can start the shader to use the new data. However, existing GPUs cannot effectively utilize these data structures, and once the size of the buffer is established, it is difficult to effectively change. For example, a GPU can execute an atomic "compare and exchange" instruction on a memory because it is difficult and inefficient to implement a ring buffer using shader instructions.

[0019] This article introduces an efficient implementation of multiple growable data queues and stack structures for highly parallelized environments. Examples of this article include methods for handling data buffer resources in a graphics processor. In one example, a pool of available memory pages is established (which is tracked by a memory pointer in a free page list, or in a linked list associated with a growable data structure descriptor). The shader element of the graphics processor can request space in which new data is written or previously written data is read, and each example of this article provides operations for effectively merging requests and demerging results in parallel for multiple shader threads. In response to a shader request, the address of the memory is calculated to be read or written to be used in parallel for multiple shader threads. In response to a received request, an operation for automatically growing or shrinking a growable data structure is provided. Prefetching can be handled in a free page list as an optimization for write requests, and prefetching in a linked list as an optimization for read requests. Tracking of out-of-order reads and writes is provided here to distinguish and summarize memory areas that have been allocated but not yet written, areas where writing has been completed but data has not yet been read, areas where writing has been completed and reading has begun, and areas where data has been written and fully used. Furthermore, tracking and summarizing of the status of the various growable structures discussed herein is provided to help prioritize dequeuing of their respective data. Also, handling of out-of-range errors is efficiently provided, such as requesting to read data that has not yet been written.

[0020] Each example of this paper further provides enhanced and effective implementation for multiple concurrent shaders operating growable data structures. In addition, the enhanced operation allows the shader to submit data to a data structure (FIFO, queue or stack, etc.), and allows the data structure to be dynamically adjusted in size, such as a dynamically "growable" data structure. However, some enhancements of this paper can be applied to statically sized data structures. The associated hardware advantageously allocates a new memory portion so that it can be written when the current portion is filled. The enhanced operation further provides simultaneous reading and writing of growable data structures, provides multiple threads using data, automatically notifies the scheduler to add work to the programmable subset of the growable data structure, allows multiple growable data structures to be accessed in parallel, and eliminates almost all delays except for the behavior of reading and writing actual data to the memory.

[0021] Although the enhanced growable data structures discussed herein can be applied to any data processing and handling environment, the examples herein are discussed in the context of a graphics processing environment. Specifically, the shader functionality of a graphics processing environment is discussed, which can be employed in a graphics processor, a GPU, or other data processing system. In addition, although FIFO, queue, or stack data structures are discussed, other data structures may also employ the enhanced features herein to include a "growable" feature. The growable data structures used in shader operations are provided by a memory, such as a random access memory (RAM) and other forms of memory.

[0022] The shader function is adopted by GPUS to apply shading, shadows, color intensity or other attributes to each element in the graphics scene to be rendered. Shaders are generally large-scale parallel elements, such as software elements or hardware-implemented elements. In modern graphics processing, shaders are provided in large quantities (such as thousands or more), and all shaders attempt to perform similar operations at the same time. For example, a GPU may have multiple hardware shader units (e.g., 4-64 or more), each of which handles multiple thread groups, such as 64 thread groups. Each thread group may also include thousands of threads running simultaneously, such as 32-1000 threads per thread group. Hardware designed to manage thousands of memory requests or thousands of push / pop requests for a single thread at the same time may be difficult, and therefore, managing associated data buffer operations in a GPU may face challenges. In shaders, list management may be complex, and existing GPU opcodes and handling techniques also exist, but these prior arts may be difficult to implement and may be inefficient on existing hardware. To provide enhanced shader operations and memory buffer operations, various elements are provided herein that can perform atomic operations and handle read and write pointers of shaders and associated data buffers, such as a buffer management element or stack / queue manager (SQM) that holds shader descriptors.

[0023] During operation, the shader pushes data into the buffer for subsequent service. The buffer management element provided herein can have "direct" and "indirect" methods for data handling. In the direct method, a memory data bus bottleneck can be created during a large number of operations performed by the shader. However, although the direct method is still bottlenecked in memory bandwidth, the direct method is more efficient than existing algorithms on today's standard hardware, and the indirect method also achieves performance gains. The direct method supports stacks, while the indirect method does not. Both direct and indirect methods allow write merging, wherein the direct method is slightly better than the indirect method in write merging. The direct method may not be able to access the full bandwidth of the memory bus, while the indirect method usually can.

[0024] However, the enhanced "indirect" method discussed herein can handle a large number of operations to efficiently use the memory data bus. In the indirect method, the shader requests space for data to be written during the shader operation. The buffer management element assigned to the requested growable data structure performs various checks to determine whether the data space can accommodate the remaining size of the current page. The buffer management element returns two pointers and a count to the shader. The first pointer is the location where the first one or more threads of the shader can start writing, the count is the number of elements that the shader can safely write to, and the second pointer is the beginning of a new page where the shader can write its remaining data elements. When the shader finishes writing its data, the shader sends a new message back to the buffer management element to indicate how many data elements the shader has written into one or two pages.

[0025] The shader may be instructed to execute "n" threads to process data, such as 64 or 128 threads. The shader may "push" data to / from the data buffer in a burst manner for multiple threads concurrently in a single request to the buffer management element. This effectively compresses the use of requests to effectively utilize memory resources and physical data bus resources. For example, if there are 64 threads in a shader thread group, the associated buffer management element will not have to handle 64 separate "start push" requests-the shader hardware (or shader program) can detect that all 64 threads want to push into the same growable data structure and send a single "start push-request space for 64 elements" command to the buffer management element. When the buffer management element sends the two pointer addresses and the count of the growable data structure back to the shader unit, both hardware or software can be used to decompress the two addresses and counts to generate a safe address for each of the 64 threads to write. The same operation may occur due to a "start pop" request. This write merging and burst reading can therefore be performed by the shader to efficiently utilize any associated memory bus. During a write or "push" operation, data for multiple threads can be combined, packed, or otherwise "compressed" into a single write operation. During a read or "pop" operation, the shader can include enhancements to distribute, unpack, or otherwise "decompress" the data combined in the read operation to ensure that each thread is provided with relevant data for processing. The shader can use various data dispatch and tracking techniques to track this merging and decomposition.

[0026] For data read operations ("pops") from the buffer, the buffer management element may provide the shader with more than one read pointer pointing to more than one page (such as when the associated data spans more than one page) and a count. The count may indicate how many elements on the first page are valid. In the event that the shader requests more data than has been written to the buffer, another count indicating how many elements on the second page are valid may also be provided. The first pointer may indicate the starting location of the data within the page, and the second pointer may indicate the beginning of the second page containing further data associated with the read operation. This is useful when the shader requests to read more than one entry from the buffer (such as 64 or 128 entries in one example). The 64 or 128 entries may each be associated with a different thread, and the entries may span more than one page. Therefore, multiple pointers may be returned for the read operation. Write merging and burst reads may therefore be performed by the shader to efficiently utilize any associated memory bus even as the buffer grows.

[0027] In some examples, there are 32 or more threads in a shader "thread group", and the thread group issues requests while the buffer management element communicates with the thread group. Hardware or software is responsible for distributing the results based on the thread group back to the individual threads in this thread group. Each thread in the thread group can specify a FIFO / stack ID and a bit indicating whether the thread "participates". For example, each thread in the thread group can request 0 or 1 items from a given growable data structure, and a mask indicating which threads of the thread group are requesting data may be provided or generated. In a further example, each thread may be configured to request space for more than one item and have some added implementation logic. When the thread group performs a "write", this write indicates whether each thread in the thread group participates in the write, such as via a mask or other indicator. However, each thread may be writing to completely scattered memory addresses, and these scattered memory addresses are handled by standard GPU functions.

[0028] Requests are typically merged by the shader program, shader unit, SQM, or some other element between the shader and the SQM. For example, with a FIFO, all threads writing to "FIFO ID 0" are grouped into a single "start push" request, all threads writing to "FIFO ID 1" are grouped into separate "start push" requests, and so on. Each SQM can handle one "start" request at a time, although multiple threads (or potentially multiple thread groups, depending on the merging algorithm) may have contributed to the request. The addresses generated by the SQM are then split apart and sent back to the corresponding shader threads. This de-merging operation can be done in the shader program, shader hardware, SQM, or some other element between the shader hardware and the SQM. Advantageously, the more merging that occurs, the better the performance.

[0029] The elements discussed herein provide enhanced "growable" buffer functionality. These growable buffers can be used in graphics processing environments (such as for shader elements) and can be provided using a pool that tracks pointers to free memory "pages" that can be allocated to growable data structures. A pool is a portion of memory that is subdivided into multiple pages of the same size that can be allocated for use by growable data structures. The enhancements herein can provide hardware or software support for one or more such pools and one or more such growable data structures. Each growable data structure contains pages from a selected pool. Several growable data structures can be allocated from the same pool, and several other growable data structures can be allocated from different pools depending on the use case, pool page size, or other factors. Various pool management implementations are discussed herein, such as ring buffers and bit arrays. However, a pool manager element is included in the hardware implementation, from which a buffer management element can allocate pages for use by data structures, and from which free pages are allocated for subsequent use by data structures. The pool manager does not understand the actual page usage, but handles page allocation and de-allocation.

[0030] The growable data structure includes memory pages that form a linked list structure. Associated pointers are used by the growable data structure to link between pages that include the growable data structure. The buffer management element may implement this linked list structure to track pages in the growable data structure. For example, the buffer management element may reserve the first or last "n" bytes (such as 8 bytes) of the page to store pointers to the next and / or previous page. Alternatively, the linked list pointer may be implemented elsewhere, which allows the entire page size to be used for data rather than reserving a portion of each page for the linked list pointer. Advantageously, the enhanced graphics processing operations herein provide the ability to handle and track multiple different growable buffer data structures that can be dynamically allocated between different shader elements or shader threads. When it is necessary to separate buffer resources between shaders or shader threads, multiple simultaneous growable buffer structures may also be implemented.

[0031] Turning first to examples of systems and platforms that can provide at least the enhanced capabilities described above, Figure 1 is provided. Figure 1A graphics processing environment 100 is illustrated in one implementation. Environment 100 includes a user system 110, a graphics processor 120, and a system processor 130. In operation, system processor 130 may boot into an operating system (OS) to provide various operations for user system 110, including user applications, data processing services, communication services, storage services, gaming services, or other features of a computing system. Graphics processor 120 may provide graphics processing and rendering services for system processor 130. Graphics processor 120 also provides enhanced operations, including operations involving example portions including shader unit 121, job launcher 122, texture unit 123, and other elements. Although graphics processor 120 is not particularly limited in scope, graphics processor 120 may be used in conjunction with system processor 130 to provide graphics processing and rendering services. Figure 1 1 is shown as a separate element in communication with processor 130 via at least link 150, but it should be understood that other examples may provide graphics processor 120 within system processor 130, such as when system processor 130 integrates elements of graphics processor 120.

[0032] User system 110 includes a computing system or computing components, such as a computer, server, tablet device, laptop, smart phone, gaming system, entertainment system, storage system, or other computing system, including combinations thereof. User system 110 includes Figure 1 As mentioned above, these components include a graphics processor 120 and a system processor 130. The graphics processor 120 and the system processor 130 may each include one or more integrated components, such as a processor core, a cache memory, a communication interface, a graphics core, and a north bridge component, as well as other integrated components not shown for clarity. In addition, the user system 110 may include various assembly elements, such as a housing element, a thermal management element, a memory element, a storage element, a communication interface, a power system element, and other elements not shown for clarity. When the graphics processor 120 and the system processor 130 are installed in the user system 110, these assembly elements provide system resources and context for the operation of the system processor 130. The display 101 may be included in the user system 110.

[0033] Housing elements may include structural support elements, housings, chassis elements, or other elements that house and structurally support additional elements of the user system 110. Thermal management elements may include heat sinks, fans, heat pipes, heat pumps, cooling elements, or other elements for managing and controlling the temperature of the user system 110. Memory elements may include random access memory (RAM), cache memory devices, or other volatile memory elements employed by the system processor 130 or the graphics processor 120. Storage elements include non-volatile memory elements such as hard disk drives (HDDs), flash memory devices, solid-state drives (SSDs), or other memory devices that store operating systems, applications, or other software or firmware for the user system 110. Communication interfaces may include network interfaces, peripheral interfaces, storage interfaces, audio / video interfaces, or other interfaces that communicatively couple the user system to external systems and devices. Graphical elements may include display interfaces, displays, touch screens, touch interfaces, user interfaces, and the like. Power systems typically include voltage regulator circuitry, controller circuitry, power filtering elements, power conditioning elements, power conversion elements, power electronics, or other power handling and conditioning elements. The power system elements receive power from an external source, such as from a battery or an external power source, and convert / regulate the power to produce voltage and current to operate the elements of the user system 110 .

[0034] User system 110 can communicate via one or more communication links (such as one or more network links). Example communication links can use metal, glass, optics, air, space, or some other material as a transmission medium. Example communication links can use various communication interfaces and protocols, such as Internet Protocol (IP), Ethernet, USB, Thunderbolt, Bluetooth, IEEE 802.11WiFi, or other communication signaling or communication formats, including combinations, improvements or variations thereof. The communication link can be a direct link, or can include an intermediate network, system, or device, and can include a logical network link transmitted over multiple physical links.

[0035] The user system 110 may include software such as operating systems, logs, databases, utilities, drivers, networking software, user applications, data processing applications, game applications, and other software stored on computer-readable media. The software of the user system 110 may include one or more platforms controlled by a distributed computing system or a cloud computing service. The software of the user system 110 may include logical interface elements, such as software-defined interfaces and application programming interfaces (APIs). The software of the user system 110 may be used to generate data to be rendered by the graphics processor 120 and control the operation of the graphics processor 120 to render graphics for output to one or more display devices.

[0036] Graphics processor 120, system processor 130, and system memory 131 may communicate via associated links 150-152. Example links may use metal, glass, optics, air, space, or some other material as a transmission medium. Links may use various communication protocols and communication signaling, such as a computer bus, including combinations or variations thereof. Links may be direct links, or may include intermediate networks, systems, or devices, and may include logical network links transmitted over multiple physical links.

[0037] System memory 131 typically includes random access memory (RAM) or dynamic RAM, and any physical or virtual allocation of other components including interface elements. System memory 131 may be shared between system processor 130 and graphics processor 120, or may be partitioned to be exclusive to either system processor 130 or graphics processor 120.

[0038] Figure 1 The graphics processor 120 in an implementation is illustrated, which may be an example of a graphics processing unit (GPU) including one or more graphics cores. The graphics processor 120 may provide graphics processing and rendering services to a system processor that directs data and instructions via link 150, such as Figure 1 The graphics processor 120 may include one or more stages or internal components that may process content / data into rendered images for display. The graphics processor 120 may communicate with the system memory 131 or dedicated graphics memory depending on the configuration. Although these elements may include Figure 1 121-125, but it will be appreciated that other configurations are possible.

[0039] Figure 1 Example elements of the graphics processor 120 in FIG. 1 include one or more of a shader unit 121, a work initiator 122, a texture unit 123, and a buffer service 125. The shader unit 121 may include one or more single instruction multiple data (SIMD) units, and the work initiator 122 instructs the SIMD to begin running a shader program. The shader SIMD and the work initiator may communicate with the buffer service 125. One or more texture units 123 (or other forms of memory interfaces) are included, and each shader SIMD requests memory through a texture unit or a memory interface. The buffer service 125 may communicate with the system memory 131 through an associated memory interface. Although the buffer service 125 may include Figure 11, but in other examples, buffer service 125 may be implemented using one or more software elements. Individual shader programs determine color, shading, and intensity information during the rendering process, and in some examples include pixel shading features. Shader unit 121 may communicate with texture unit 123 to determine the color / shading of a textured area, which may be referred to as a texture pixel (texel). One or more buffer managers may be included in buffer service 125 to provide many of the enhanced memory and data structure handling operations discussed herein.

[0040] Figure 2 An example method 200 of operating a data buffer handling system is illustrated. Figure 2 Operation in Figure 1 However, Figure 2 The operation can also be applied to Figure 3-6 Components. Figure 2 , graphics processor 120 establishes (201) a pool of available memory pages for use in a growable data structure, each available memory page being tracked by a memory pointer. In some examples, buffer service 125 or an associated pool manager element may use tracking data structure 132 to establish this pool of available memory pages. Growable data structures such as buffer structure 133 may be increased or decreased in size based on the dynamic needs of data processing elements such as shaders of a GPU. Typically, the pool of available memory pages is tracked in an associated tracking data structure 132 using pointers to memory pages that are pre-fetched or pre-allocated for subsequent use. Tracking data structure 132 may also include a ring buffer structure in addition to other data structure types. Pointers to each memory page may therefore be stored in tracking data structure 132.

[0041] Buffer service 125 may receive (202) a request for space in buffer structure 133 into which shader data or other associated data is written from a data processing element, such as shader unit 121. Buffer service 125 provides (203) pointers to memory pages from buffer structure 133 based on the data size indicated in the request. These pointers may be used by the data processing element to write shader data to buffer structure 133.

[0042] The buffer service 125 also tracks the amount of data written to the buffer structure 133. Various thresholds may be established to monitor when to increase or decrease the buffer structure 133. For example, when a threshold fill amount of the buffer structure 133 is reached (204), or if a request indicates a write size that exceeds a threshold amount, the buffer structure 133 may increase the size of the buffer structure 133 using memory pages in a pool of available memory pages tracked by the tracking structure 132. The buffer service 125 may pre-fetch (205) memory page addresses, such as from a free page list, for inclusion in the buffer structure 133 from the pool of available memory pages. In this way, memory page addresses may be prepared in advance to be used in the buffer structure 133, and the buffer service 125 may respond quickly to data buffer needs of the shader unit 121 in a dynamic manner. In addition, when a threshold amount of data has been removed from the buffer structure 133, such as in response to consumption of shader data in one of the memory pages, the buffer service 125 may return the memory page to the pool of available memory pages. To return these memory pages to the pool, the buffer service 125 may reintroduce pointers to those memory pages into the tracking structure 132 .

[0043] Some portions of the tracking structure 132 may be located in the system memory 131 (such as the free page lists discussed herein), but many other portions may be located in the buffer services 125 (e.g., FIFO descriptors), or may be located in the system memory 131 but cached / prefetched in the buffer services 125 (such as free page lists or linked list pointers). In addition, various other tracking structures may be employed, and they are generally distinguished from each other. First, a buffer tracking structure may be established that stores various "thresholds" for each buffer structure. Second, a tracking list of free pages may be established. A tracking structure of pointers to the beginning and end of the free page list may be established. Likewise, the "linked list" pointers may be located in the associated buffer structure itself, or in a separate structure. A tracking structure of per-page "bytes / element consumed" and "bytes / element added" counters may be established, which may be embedded at the beginning or end of each page in the buffer structure (next to the linked list pointers), or may be stored in a separate structure.

[0044] Figure 3 A data buffer handling system and process in one implementation are illustrated. Figure 3In the embodiment of the present invention, data processing environment 300 includes graphics processing unit (GPU) system 310, buffer management service 301 and memory system 360. GPU system 310 includes one or more GPUs controlled by a master processor and coupled via an associated data bus or data link (such as a PCIe (Peripheral Component Interconnect Express) link). This master processor (not shown in the figure for clarity) Figure 3 300 ) may include a central processing unit (CPU). The GPU system 310 is communicatively coupled to the memory system 360 via one or more memory buses 380. The GPU system 310 may include elements of a buffer management service 301, and Figure 3 All elements of the GPU system 310 may be integrated into a single chip device, a system on a chip, a GPU, or a plug-in card configuration for a computing system. In some examples, the GPU system 310 includes a hardware processing element including the buffer management service 301. In other examples, the GPU system 310 includes a software processing element including the buffer management service 301.

[0045] The queue manager 320 includes one or more software / hardware processes or services that are configured to receive space requests for memory pages from data processing elements such as shaders 311. The queue manager 320 provides memory page addresses to the shaders 311 via pointers for use in shader operations or other data processing operations. The queue manager 320 can provide a dynamic amount of buffer space for use by the shaders 311. This buffer space can be provided by a data structure 361 that can be increased or decreased according to the dynamic needs of the shaders 311. The queue manager 320 can communicate with the pool manager 340 to dynamically adjust the size of the associated data structure 361 and retrieve pointers to free pages.

[0046] The pool manager 340 includes one or more software / hardware processes or services configured to maintain one or more pools 362 of memory pages that can be allocated for use by the shader 311. The pool manager 340 uses a free page list 341 to track available / free memory pages. The free page list 341 includes one or more data structures that track currently available memory pages using associated pointers to memory pages. The free page list 341 may reside in the system memory, but for efficiency, a portion of the free page list 341 may be pre-fetched by the pool manager (one or more) 340. The page pool 362 resides in the memory system 360, such as in RAM, GPU memory, system memory, or other associated memory locations. Free pages may be added to or removed from the data structure 361 according to the current memory requirements of the shader 311 or other data processing elements of the GPU system 310. When the amount of free space in the data structure 361 drops below a certain threshold, a new page 363 may be allocated to the data structure 361 in anticipation of the associated shader use. Optionally, when more than a threshold amount of free pages are allocated into data structure 361, these free pages may be returned or de-allocated as freed pages 364. These freed pages may be returned to pool 362 for use by other data structures.

[0047] Although pool 362 is typically predetermined in size, such as ~1 gigabyte (GB), adjustments may be made to pool 362 during operation if data structure 361 or other data structures use more pages from pool 362 than are currently available. Typically, pool 362 may use a fixed virtual address range, but associated GPU memory conversion services may be employed to add or delete physical pages from pool 362 based on current needs. For example, if pool 362 is almost empty, but some other program requires a large amount of physical memory, many pages may be deleted from the "free page list" so that the pool manager does not hand them over to the queue manager. The affected pages may be deleted from the page table for other purposes. Requests to "un-back" pages are typically generated by the CPU, although work launchers or shaders may also generate "un-back" requests.

[0048] The queue outliner 330 includes one or more software / hardware processes or services configured to monitor various elements of the buffer management service 301. These monitored elements may include the queue manager 320 and the pool manager 340 and their activities. The queue outliner 330 may also monitor the pool 362, the free page list 341, the free page usage, and the status of the data structure 361. This status may indicate usage statistics, fullness, page changes, page allocations, page deallocations, the size / fullness of the page pool, the free pages indicated in the free page list 341, or other status. An example function of the queue outliner 330 is to notify the work launcher when one or more elements have been pushed into any of the data structures 361, so the work launcher can launch the shader that will use this data.

[0049] Now turn to Figure 1 and 3 Further detailed operation of each element is shown Figure 4 . Figure 4 Another example data buffer handling system and process in an implementation is illustrated. Figure 4 A processing environment 400 is included. The processing environment may include a central processing unit (CPU), a graphics processing unit (GPU), or other elements of a computing and data processing system. For example, the processing environment 400 includes a data processing 410, which further includes a shader launch scheduler 411, a shader processing unit 412, and a controller 413. The shader launch scheduler 411, the shader processing unit 412, and the controller 413 may include elements of an associated GPU or CPU. Figure 4 Also included are one or more buffer management elements, including a stack / queue manager (SQM) 430, a pool manager 440, a per-page information manager 450, and a queue outliner 420. Although Figure 4 Only one instance of each stack / queue and buffer management element is shown, but in further examples, multiple instances may be included and used for dedicated shader elements or for load balancing between many shader elements. Figure 4 The growable data structures are referred to as stacks / queues in the examples, but any suitable data structure type may be used, including various subtypes of queues, such as FIFOs. In addition, the examples herein also support random access growable structures or multi-purpose queues (e.g., write once, read more than once, then release; or write once, then read / modify / write, then read again).

[0050] Figure 4The buffer management element included in is responsible for interfacing with one or more enhanced stacks or queues used as buffers as described herein, such as the example buffer pool 465 in memory 464. One or more shader processing units (SPUs) 412, each processing an associated GPU shader thread (typically in a single instruction, multiple data (SIMD) manner) will be connected to one or more SQMs 430 via one or more associated data buses (i.e., daisy chain, branch, crossbar, or other manner), so that each SPU can send commands to each SQM, and so that any given stack / queue described herein can be exclusively owned / managed by a corresponding SQM.

[0051] For each stack / queue buffer managed by an associated SQM 430, the associated SQM locally stores information / descriptors 432 related to the operation of the growable stack / queue. The SQM 430 includes sufficient local data storage to include information / descriptors for multiple sets of stacks / queues. This information may include:

[0052] The size of each element stored in the stack / queue

[0053] The size of the stack / queue

[0054] The number of elements allowed in a page

[0055] Base address in stack / queue memory

[0056] For the page currently being written - an indication of the index of the "current write pointer" (WPTR)

[0057] For the page currently being read - an indication of the index of the "current read pointer" (RPTR)

[0058] For growable buffers, this information can also include:

[0059] Pointer to the base address of the current page being written

[0060] Pointer to the base address of the current page being read

[0061] Pointer to the base address of the next page to be read

[0062] An indication of the amount of space remaining for writing in the currently written page

[0063] An indication of the number of elements remaining in the current read page.

[0064] These stacks / queues managed by the SQM may have multiple supported combinations of features or mode styles / types. Example styles / types include read / write styles / types. These read / write styles / types may include temporarily writing only (Temporarily Write-only) as a stack, temporarily reading only (Temporarily Read-Only) as a stack, temporarily reading only as a queue, temporarily reading only as random access, reading and writing (Read-Write) as a stack, reading and writing as a queue, and writing as a queue but reading as random access. Further modes include whether the SQM directly reads / writes data to a buffer (direct access), or whether it only provides appropriate arbitration and guidance for the shader but allows the shader to directly access the data (indirect access). In an indirect example, the shader processing unit 412 can use an indirect push / pop command to read / write an element 466 via a link (dd). Further example stack / queue modes may include non-growth, growable (manually released pages), and growable (automatically released pages).

[0065] As mentioned above, depending on whether the stack / queue operation is direct or indirect, the shader may send various commands to the SQM 430 in order to interface with the stack / queue. For the "direct" access style of the buffer, the SQM uses push and pop commands to interact directly with the stack / queue. The push command includes when the shader provides data, the associated SQM responsively allocates space for the data, the associated SQM writes the data to the memory, and the associated SQM optionally also returns an address indicating where the data is written to the shader. The pop command includes when the associated SQM retrieves and provides data to the shader, and if no data is available, an error indication is provided.

[0066] For the "indirect" access mode of the buffer, various commands that allow the shader to notify the associated SQM of the intended operation are included. Specifically, Push_alloc, Push_done, Pop_alloc, and Pop_done commands can be used. In the Push_alloc command, the shader notifies the associated SQM shader that the data is to be placed in the stack / queue, and the associated SQM provides the shader with a safe memory address to be written. Similarly, for the Push_alloc command, the associated SQM notifies the appropriate per-page information manager that the space has been allocated. In the Push_done command, the shader notifies the associated per-page information manager that the shader has completed writing the data to the stack / queue, and therefore the data can be used safely. In the Pop_alloc command, the shader notifies the associated SQM shader that the data is to be retrieved from the stack / queue, and the associated SQM provides an address for reading or some "empty" indicators (such as a NULL pointer) to indicate that there is no data remaining. Similarly, for the Pop_alloc command, the associated SQM notifies the appropriate per-page information manager that space has been allocated. In the Pop_done command, the shader notifies the associated per-page information manager that the shader has completed reading data from the stack / queue. In an example involving a non-growth ring buffer, the space just read can be reused for writing. Additionally, further commands can be used to randomly access growable auto-release buffers. The Write_flush command can instruct the associated SQM to flush any cached data to the memory. The Read_done_for_autofree command can indicate to the associated SQM that the shader has completed reading some data on a given page. The associated per-page information manager will responsively calculate how many unfinished reads there are on the page and release the page after use. Depending on the instruction, the SQM will receive data or addresses from the shader and will return a "done" indicator for writing, data for reading, or an address for an "alloc" instruction.

[0067] In order to implement a growable buffer, multiple SQMs can communicate with one or more shared pool managers 440. Pool manager 440 tracks a list of free pages for use by hardware components such as data processing 410. Pool manager 440 can be implemented as a ring buffer discussed in the examples of this article, or alternatively implemented using a bit array indicating which pages are free. The pool ring buffer method is more flexible, in part because the ring buffer can support pools of any size with any non-continuous pages. On the contrary, although the bit array is easier to implement, it is of fixed size and only supports virtual continuous pages. If there are multiple SQMs, pool manager 440 will usually be shared so that any given pool manager can be accessed by all SQMs. Pool manager 440 effectively implements a direct, non-growth ring buffer of a read / write style for special cases, which contains a list of pointers to free pages in the pool. When SQM detects that a growable buffer is about to overflow the associated page, SQM will request a new page from the pool manager. To reduce latency in fetching data from the special case pool ring buffer, the ring buffer can be stored in the pool manager itself, or an automatic prefetch cache can be implemented as part of the pool manager to preload a list of available page pointers. The automatic prefetch cache can be sized appropriately to hide memory latency in a given implementation.

[0068] The shader unit can be configured to use a single instruction, multiple data (SIMD) style of operation. Typically, 32 or more shader threads process data together and execute instructions together in groups called "waves", "wavefronts", "threadgroups", or other groupings. Due to this SIMD nature, "push" and "pop" instructions can be executed on 32 or more threads at the same time. Thus, for example, the SQM can receive a "push" command with data from 32 or more threads. A mask indicating that some threads choose not to participate in the instruction can also be received with the command. To improve efficiency, the SQM can implement some operations that can atomically allocate space on the current page of the stack / queue, allocate a new page for a growable buffer when the space on the current page is exhausted, and write data for multiple threads in the shader SIMD (perhaps writing half of the data to one page of the growable buffer and the other half of the data to another page of the growable buffer). The request combiner 431 combines requests from a given wavefront, or potentially across multiple wavefronts, into a single command that is passed to the SQM or to the page atom 451 over link 478 / 479.

[0069] To further describe combining many thread requests into a single request, various elements can detect that multiple threads (such as 64 threads) all want to push data into the same growable data structure (such as the same stack / queue). Alternatively, a subset of requests can be directed to a first stack / queue, and another subset is directed to a second stack / queue, and more than one combined request can be determined. However, multiple requests combined into a single request are used to request a space into which data can be pushed (or similarly for a space from which data can be popped). Therefore, the SQM can receive a single combined request for buffer space of multiple threads. This process can be referred to as request combination, request merging, request grouping, and other similar terms, and requests from threads of a thread group are usually combined into a single request. If the data space indicated by the request is greater than the data space that can be provided by a predetermined number of memory pages (such as two or some other suitable thresholds), the request can be combined into a corresponding number (i.e., 2) of merged requests, rather than a single merged request. In some examples, requests can be combined across shader thread groups or across shader units, such as when these request spaces are located in the same growable data structure. Request combining can be performed in various elements, such as in a shader program, a hardware shader unit, a crossbar 431, or other elements. In another example, request combining can be coordinated between threads that coordinate / cooperate to cause one or more specified threads to issue combined requests for multiple different threads. When the crossbar 431 is used to combine requests, advantageously, requests from more than one shader unit or thread group can be combined.

[0070] In response to a combined request, the atomic operation processor 433 may identify the request as combined (or non-combined, if so configured), split the request into individual space requests to determine the size between the pages that will be used to satisfy the request, and return a pointer to the requesting thread indicating the push or pop location in the growable data structure. When the request indicates enough space to cross a page boundary, the atomic operation processor 433 may split the requested space across more than one page to ensure that individual threads do not have to cross page boundaries. As indicated above, a threshold for a predetermined number of maximum pages may be established, and thus the atomic operation processor 433 may split the space until the predetermined number of maximum pages is reached.

[0071] When work is written to the stack / queue, the SQM may send or broadcast a message to the queue summarizer (QS) 420. The QS 420 may receive messages about the current state of the stack / queue 466 or buffer pool 465 from the incomplete write count cache module 434 via link 477. In addition, the shader launch scheduler 411 may request information for non-empty stacks / queues from the queue summarizer 420. The shader launch scheduler 411 may then provide the shader launch scheduler 411 with results related to the current state of the stack / queue 466 or buffer pool 465. These messages may indicate stack / queue states / attributes, such as messages such as "buffer is full", "32 new entries have been added to this queue", "queue is empty", "pages have been allocated", or "there are almost no free pages in the pool". Additionally, error messages may be sent by SQM 430 to QS 420, such as "pop performed when no data was available", "push performed but buffer space exhausted", or "push_done / pop_done received but not expected", among others.

[0072] QS 420 can be programmed to assign priorities to various stacks / queues based on load balancing considerations between shader threads or shader elements. In addition, QS 420 can be programmed to assign priorities to various stacks / queues based on the order in the task graph, based on the number of work items that can be processed in a given pool ring buffer, based on the availability of resources, or based on other considerations, including their combination. QS 420 can track this information of each queue / stack internally. Shader launch scheduler 411 can instruct QS 420 to find one of the highest priority stacks / queues with the most urgent data / work to be processed that SQM 430 has. Based on criteria, QS 420 can provide information related to the corresponding stack / queue back to shader launch scheduler 411 so that the scheduler can start a new shader thread group to process data from this stack / queue. QS 420 can respond to inquiries related to stack / queue fullness or other states / attributes of stack / queue issued by other processes. For example, as mentioned, a process may query the QS 420 to determine which stack / queue has the most relevant amount of data yet to be serviced or "work" to be processed, and priority may be determined based in part on this workload of a particular stack / queue. The stack / queue may be drained based on the current fullness to efficiently execute the workload of the shader operations. The QS 420 may provide fullness status using various indicators such as a 2-bit indicator with "empty", "1-31 entries", "32-1000 entries", or "greater than 1000 entries", as well as other thresholds and indicators.

[0073] Now turn to Figure 4For further discussion of the elements and operations of Figure 4 Specifically, memory 464 may include stacks / queues 466A-466C, which may each hold data related to the operation of the shader elements of data processing 410. Memory element 460 illustrates a memory interface element that stores and retrieves data in memory 464. Memory arbiter 462 handles arbitration between various data inputs / requests to memory 464 via link 495. Result-directed module 463 handles the processing of data received via link 496 to the memory 464. Figure 4 For clarity, the memory outputs of the various components are transferred. Figure 4 Included in FIG. 1 are alphabetical input / output nodes, namely nodes a, b, c, d, m, n, p, x, y and z, which illustrate the interconnections between associated elements.

[0074] SQM 430 interfaces with the shader elements and other control elements of data processing 410. In operation, data process 410 may initiate commands and data on links 471-472 for SQM 430 to handle. Prior to this, controller 413, which may include a CPU or other processing element, may issue one or more setup commands to elements 430, 440 and 450 via link 473 to initialize hardware instances of elements 430, 440 and 450, buffer pool 465, instances of stack / queue 466, base addresses of indicating stacks / queues or other setup and control instructions. The setup commands may indicate to elements 430, 440 and 450 how many stacks / queues will exist in memory, as well as the initial state of the pool free page list. In direct push / pop handling, SQM 430 handles these commands related to stack / queue 466 on behalf of the shader elements. In addition, SQM 430 is responsible for providing updates based on data activity in stack / queue 466 regarding page pointers, read / write pointers, and other pointers associated with stack / queue 466. SQM 430 may provide status information about stack / queue 466 or buffer pool 465, as well as other status information of elements 430, 440, and 450 to queue summarizer 420.

[0075] Command arbiter / crossbar / request combiner 431 acts as a front-end interface to data process 410. The command arbiter / crossbar function may arbitrate and transmit commands issued by data process 410 for use by selected elements of SQM 430 via selected links 478, 479, and 480. These commands may include commands to obtain stack / queue descriptors via link 478, commands to initiate push, pop, direct push, or direct pop operations via link 479, and commands / data to perform direct data pushes via link 480, among other commands.

[0076] The request combiner function of element 431 may include combining multiple requests for burst commands. During a write or "push" operation, the request combiner function may include an enhancement to combine, pack or "compress" data for multiple threads into a single write operation. In another example, multiple shader threads may request space for reading or writing shader data, and multiple requests may be merged or combined into a single request for one or more byte spaces by request combiner 431. The response to the request (including an associated pointer to a memory page and indicating the remaining valid space) may be unpacked by hardware or software when returned to the shader thread, so that each shader thread making a request receives a unique pointer to the memory that it can read or write. Advantageously, many shader thread space requests may be processed simultaneously. The request combiner function may pack "pop-up" requests from multiple threads together, so that element 432 / 433 / 435 / 436 and / or element 451 / 452 / 453 only needs to handle a single combined request, rather than a request for 32 or more thread sizes. During a read or "pop" operation, path 474 or unit 412 may include enhanced functionality to distribute, unpack, or otherwise "decompress" the data combined in the read operation to ensure that each shader thread is provided with relevant data for processing.

[0077] The stack / queue descriptor module 432 includes functionality to provide descriptors, a "current read pointer" (RPTR) of the stack / queue 466, a "current write pointer" (WPTR) of the stack / queue 466, etc., to the atomic operation processor 433 via link 481. The stack / queue descriptor module 432 may also provide information related to a pointer to an outstanding write count cache 434 via link 483. The stack / queue descriptor module 432 receives updates to the RPTR, WPTR, current page status, etc. from the atomic operation processor 433 via link 482. The atomic operation processor 433 handles various operations of the SQM 430, such as placing data push / pop commands into the stack / queue. In addition, the atomic operation processor 433 updates the RPTR, WPTR, current page status, counts, etc., which may be provided to other modules. The atomic operation processor 433 may also provide WPTR completion increments and RPTR allocation increments to the outstanding write count cache 434 via link 485. The atomic operation processor 433 also issues update commands for writing allocation pointers and reading allocation pointers to the cache manager 452 through the link (pp).

[0078] The atomic result from the atomic operation processor 433 is provided to the address generator 435 via link 484. The address generator 435 generates addresses for direct push / pop commands based on the atomic result and passes these addresses to the push-pop memory request module 436 via link 486. In addition, the address generator 435 generates addresses for allocation commands based on the atomic result, and these addresses are returned to the shader element of the data processing 410 via link 474. The generated addresses for direct push / pop commands are provided to the push-pop memory request module 436 via link 486, which uses these addresses in direct push operations with respect to the memory arbiter 462 via link (aa). Data for direct push is received via link 480, and these data are combined with the address and any associated mask to cause a direct push operation to be performed on the stack / queue 466 via link (aa). The data or write confirmation for direct pop is provided from the result-directed module 463 via link (xx) to be passed to the shader via link 474.

[0079] The "Push allocation" function of the atomic operation processor 433 atomically allocates memory space from the page to be written, checking whether the allocation crosses a boundary (such as filling a full page). If the boundary is crossed, the push allocation function can allocate a new page to obtain more space, which may include communicating with the pool manager 440 to receive the address / pointer to the new page. The push allocation function then updates the write pointer, tracks the outstanding writes to the page, and directly writes the data and / or returns the address to the shader where the data can be safely written. The "Push_done" and "pop_done" commands are sent directly from the request combiner 431 to the per-page information manager 451 via link (nn). The per-page information manager 451 decrements the per-page outstanding write count. If the count reaches zero, the push completion function can update the "safe to read" pointer (referred to herein as the "write done" pointer) via link (mm) via the per-page cache manager 452. The push done function then updates the count of unused data in the growing stack / queue and optionally sends a message indicating that the stack / queue has changed state. The "pop allocate" function of the atomic operation processor 433 automatically allocates memory space from previously written data, checks whether this allocation crosses the end of the page, or whether this allocation crosses the end of the written memory, and then updates the read pointer and increments an outstanding read counter per page. The pop allocate function then returns the data directly and / or returns the address (and a signal indicating validity) to the shader that obtained the data. The "pop done" function of the atomic operation processor 433 atomically reduces the count of outstanding reads for the page via the per-page cache manager 452, and releases the page if the count reaches zero (and the page has been completely written). The page free indication is sent over link 490.

[0080] The pool manager 440 handles various operations related to maintaining a pool of memory pages for inclusion into the stack / queue 466 as needed. The pool manager 440 uses a data structure such as a ring buffer to track free pages in the pool 465. The pool manager 440 pre-fetches the addresses of pages using this data structure as needed, based on a threshold of how many entries have been used from its local free page list cache 442. In some cases, such as when too many free pages remain in the stack / queue 466, the pool manager 440 may also be instructed to de-allocate pages from the stack / queue 466. During operation, the atomic operation processor 433 communicates with the pool management module 441 to handle the size management of the stack / queue 466. The atomic operation processor 433 issues commands to the pool management module 441 via link 487 to allocate new pages from the pool of available pages into the stack / queue 466. The pool management module 441 may instruct the free page list cache 442 to send the addresses of these new pages added to the stack / queue 466 to the atomic operation processor 433 via link 488. The free page list cache 442 has the address of the page because the free page list cache 442 pre-fetched those addresses from the free page list. The free page list cache 442 caches a portion of the free page list. Write combining in the free page list cache 442 is typically used when enough pool pages are freed, which advantageously writes those page addresses back to the free page list, rather than just keeping those page addresses cached locally in the free page list cache 442. The pool management module 441 issues push / prefetch / pop commands to the free page list cache 442 via link 489. The free page list cache 442 issues a page pointer pre-fetch request via link (bb) and the memory arbiter 462 to pre-fetch a memory page pointer from the free page list 467 in the memory 464 for subsequent inclusion in the stack / queue 466. The pre-fetch result is provided from the result-directed module 463 via link (yy), and the pre-fetch result includes address pointer information for the pre-fetched page. The complete free page list 467 is included in the memory 464, and the free page list cache 442 includes a cache of a portion of the list 467. The cache 442 is instructed to extract a portion of the list 467 as needed. Specifically, the pool management module 441 instructs the cache 442 to output one or more free page list entries (as addresses / pointers) to the module 433 via link 488, or to push some newly released pages due to a request via link 490. The pool management module 441 tracks the head and tail of the free page list 467, tracks the number of entries that have been extracted and not yet used in the cache, and then instructs the cache 442 to pre-fetch more entries from the free page list 467 when the number of valid cache entries exceeds a predetermined threshold. Advantageously, this operation provides a pre-fetch read-write cache dedicated to using a ring buffer. In an additional example, the free page list 467 can be implemented as a stack.

[0081] The per-page information manager 450 handles the management of the actual memory pages in the stack / queue 466, primarily with the aid of the cache manager 452. This management may include updating the per-page read / write data pointers in the stack / queue 466, handling the linked list pointers that form the stack / queue 466, tracking the fullness / status of each page in the stack / queue 466, and page management transactions on the actual pages used in the stack / queue 466. Page management transactions may include handling information used to manage the linked list, such as read / write pointers and fullness / status, which may be stored in the page header or footer or in some separate buffer depending on the implementation. The per-page information manager 450 is responsible for caching this page management information, storing it in memory, and loading or prefetching it on demand. The per-page information manager 450 also tracks outstanding reads and writes per page, maintains and traverses the linked list of pages (a growable stack / queue includes a linked list of these pages), and releases pages when necessary. The per-page information manager 450 may also extract or evict per-page information as needed (such as when the cache becomes full). The page atomic module 451 provides messages related to when the write done pointer completes the page via link 491 and receives various other messages from the cache manager 452 via link 492. The page atomic module 451 may also receive end_push and end_pop commands from the command arbiter 431. The page atomic module 451 receives these end_push and end_pop commands in order to keep track of how many data elements have been completely written or read.

[0082] The cache manager 452 and the page atomic module 451 interface with the page header cache memory through associated links 494 and 493. The page header cache memory 453 includes cache lines that cache information related to the pages that form the stack / queue 466. Each cache line of the page header cache memory 453 may include various information of the corresponding page of the stack / queue 466, such as the address of the next page, the address of the previous page, the number of unfinished reads on the current page, the number of unfinished writes on the current page, the currently allocated write pointer on the page, an indicator of whether the page is the current "write allocation pointer page", and an indicator of whether the page is the current "write completed page" and an indicator of whether the page is the current read page. Other information. This information can be stored in the page header or page footer of each page of the stack / queue 466 (such as the following Figure 6601-603 in ), or stored in a separate structure in a pool or other location. This information may be cached in the page header cache memory 453 for faster / local access by the page atomic unit 451. Typically, the page header buffer memory 453 has a limited size and may not be able to accommodate all information related to all pages in use in its memory. Therefore, if necessary, such as if the page header buffer memory 453 runs out of space, the page header buffer memory 453 may store the associated data to the memory 464 (to the location discussed above) and obtain similar data from the memory 464 associated with different pages. The size of the page header buffer memory 453 can be adjusted large enough that this does not need to be done often. Link (cc) is adopted to write data to the various pages of the stack / queue 466 to update the page header associated with the stack / queue 466, or to issue a read request for the page header information associated with the stack / queue 466. Link (zz) is adopted to return the page header information and also indicate when the page header information has been completely written. Link (mm) is employed to provide the SQM 430 with a write done pointer update message.

[0083] The page atomic module 451 receives "push_done" and "pop_done" messages. The per-page information manager 450 also tracks outstanding writes and passes "write_done" messages to 431 / 432 via link (mm). In this context, "outstanding" refers to space allocated by push_alloc but not yet marked as completed by the "push_done" instruction. The cache manager 452 is notified of the "push_alloc" operation via link (pp). Because there are many shader processing units that may be executing push_alloc / push_done instructions concurrently, push_done instructions may return in a random order relative to their corresponding push_alloc. There are two example processes to handle this scenario.

[0084] The first example process is to track each element of each page with one bit. One or more bits are set on push_alloc, and those one or more bits are cleared on the corresponding push_done. A "crawler" can iterate over the bits between the current "push_done" and "push_alloc" pointers, and update "push_done" when the crawler finds a bit that has been cleared. However, the crawler approach has limited performance with growable data structures, in part because a particular page may contain a hundred thousand elements, so storing one bit per element would result in a very large data overhead per page.

[0085] A second example process is now described in detail, which works well with growable data structure implementations (such as stack / queue 466). Each page has a write-done pointer for writes completed within that page, and each stack / queue has a write-done pointer that is updated by updating the write-done pointer for the oldest page. The second example maintains a count of incomplete writes (per page), and another count of incomplete reads. Whenever the write count reaches 0, the write-done pointer for this page is updated to point to the write-allocated pointer for this page. If the write-allocated pointer has moved to another page, the write-done pointer is updated to point to the end of the current page. Therefore, each page has a "write-done" pointer and a "write-allocated" pointer. The cache manager 452 keeps track of which page is the current "write-done" page and which page is the current "write-allocated" page for each growable data structure. If the page is the current "write done" page and its write done pointer is updated, the cache manager 452 sends a message to the SQM 430 via link (mm) to indicate that the SQM 430 should update the write done pointer of the corresponding stack / queue 466. When the write done pointer of the write done page reaches the end of the page (and the write allocation pointer has moved to the new page), the cache manager 452 instructs the SQM 430 to update the write done page pointer to point to the new page. The cache manager 452 also sends a message to itself indicating that the cache manager 452 should check the new write done page and see if the corresponding write done pointer should also be forwarded to the SQM 430. The read done pointer is managed in a similar manner to the write done pointer, except that the cache manager 452 can optionally send a read done pointer to the SQM 430. When the read done pointer crosses a page boundary, the page atomic module 451 sends a message to the pool management module 441 via link 490 to release the page.

[0086] Advantageously, the examples herein discuss various enhanced methods for handling growable data structure (stack / queue) resources such as in a graphics processor / GPU. The growable data structure may include memory pages forming a linked list structure. The buffer management element may implement a linked list structure to track pages in the growable data structure. The associated pointer is used by the growable data structure to link between pages including the growable data structure. The buffer management element may use pointers to free memory pages in a separate free page list to allocate memory pages to and unallocate memory pages from the linked list structure. The graphics processing operations enhanced herein provide the ability to handle and track multiple different growable data structures that can be dynamically allocated or read between different shader elements or shader threads. Multiple simultaneous growable data structures may also be implemented when it is necessary to separate data structure resources between shaders or shader threads.

[0087] Figure 5 An example free page list / tracking structure 500 in one implementation is illustrated. Figure 5 Presented to illustrate an example free page list structure as a ring buffer 501 . Figure 5 Examples 510, 520, and 530 in FIG. 5 are linear representations of a "ring" structure of ring buffer 501, where the right hand side of each example buffer wraps around to the left hand side of the associated buffer to form a "ring" structure. These ring buffers may contain any predetermined allocation size, such as 8 kilobytes (KB), among other sizes. These ring buffers may reside in main memory, such as Figure 4 464, or other memory locations for use by the buffer manager, SQM, or pool manager discussed herein. In another example, the free page list may be implemented as a stack / queue in the pool, such as another instance of stack / queue 466. The free page list may reside in pool 465 (as a separate allocation), or it may reside in other locations in main memory 464. In yet another example, the free page list may reside elsewhere, such as entirely in on-chip cache 442. Other data structures besides the ring buffer may also be used to track the free page list, such as a bit array, where each bit of index N indicates whether the page of index N is free or in use. In a bit array implementation, the array will typically be entirely on chip, and the bit array memory will replace the free page list cache 442.

[0088] Figure 5 The ring example in Figure 4The pool manager 440 of the embodiment of the present invention is adopted to track the free page used in the growable data structure.As more data need to be stored in the growable data structure, the ring buffer will indicate the free page via a pointer (e.g., 8-byte pointer) pointing to the page.In some examples, the ring buffer may include 1000 or more entries (i.e., 1000 8-byte pointers), but the usage of 1000 entries may be distributed, used, and then returned to the free page list and changed along with the page.Therefore, the free page list tracks the page that has not yet been distributed for the growable data structure (e.g., stack / queue) discussed herein to use.

[0089] The pool manager 440 can pre-fetch pointers to pages from the free page list 467 for use with the growable data structure, and store pointers (511, 521, 531) to the pre-fetched pages in a ring buffer. This pre-fetching can be performed in response to detecting a threshold usage state of the pre-fetched pages, and pre-fetching more pages in response to the remaining valid pointers in the free page list cache 442. It should be noted that the free page list tracks pointers to free pages for use by the stack / queue. Since the stack / queue contains a linked list of pages, and these pages can be used to grow the stack / queue structure, pointers between the pages are used to link new pages to existing pages. When pages have been serviced and data has been used, the pool manager can return these pages as free pages to the free page list for subsequent use.

[0090] During the initial state, the free page list might initially be associated with 100 megabytes (MB) of memory, which is subdivided into "pages" representing sub-divisions of the 100MB. The free page list will hold pointers to each free page in memory, and the memory address of the page that contains the pointer. Pages can be allocated for use in a growable stack / queue, and once data has been used from the associated pages, they can be returned to the free page list.

[0091] When pages become available for stack / queue use, the write pointers (514, 524, 534) will advance through the ring buffer and possibly wrap, as shown in example 530. The read pointers (513, 523, 533) will indicate where to read new stack / queue space (free pages) and will advance as pages are allocated to growable stacks / queues for data storage. Figure 5 As shown in the example ring buffer of , pre-fetch pointers (511, 521, 531) pointing to free pages may also be employed. Since pages may be used and returned to the ring buffer in a random order, the pointers to free pages retained in the ring buffer may become "random" over time, even if they were initially placed in order in the ring buffer during initialization.

[0092] In the first example 510, the ring buffer 501 has an "almost empty" state as shown. In the second example 520, the ring buffer 501 has an "almost full" state as shown, where the ring buffer indicates more available pages than in example 510. In the third example 530, the ring buffer 501 has a "wrapped" state as shown, with pointers to available pages wrapped around the border of the ring buffer.

[0093] Write-combined portions (512, 522, 532) are also indicated in the example ring buffer. When pointers for pages are suspended waiting to be pushed into the ring buffer, these write-combined portions are used to efficiently process for subsequent reuse in stack / queue operations. In order to effectively utilize the associated memory bus to put these pointers back into the ring buffer, a burst of combined writes can be established. For example, if each pointer is represented by a DWORD block, these individual pointers may be released from service in the stack / queue at a first "slow" speed. However, the pool manager may not want to write each DWORD to the memory immediately. Typically, the width of the GPU to the main memory memory bus is greater than the DWORD size, so writing DWORDs immediately and individually wastes memory bandwidth. Advantageously, the pool manager can buffer the pointers to the pages into a group (as write-combined data) and then perform a burst write on the associated memory bus to fill the entire associated memory bus transaction size, or buffer until some threshold condition initiates a refresh of the write-combined data. A burst may contain 32 bytes or more, so 4 or more DWORD sized pointers may be included to be returned to the ring buffer simultaneously.

[0094] Other implementations may manage a list of free pages without using a ring buffer. Although the ring buffer approach is generally more flexible, other implementations may be less complex to implement. In this example, the pool memory must be contiguous and subdivided into pages. The pool manager then stores one bit per page: the bit is set to "1" if the page is free and to "0" if the page is in use. "Allocating" a page from the list of free pages involves finding some non-zero bits in the bit array, returning the address of the corresponding page, and then clearing the bit to zero. "Releasing" a page involves setting the corresponding bit = 1 again. The type of implementation of the free page list is slightly less important than the implementation of the "push-alloc / push-done / pop-alloc / pop-done" instructions and page cache. Although the hardware should still have some form of free page list implementation to implement the growable data structure feature.

[0095] Figure 6 An example growable data structure in one implementation is illustrated. Figure 6Included are example data structures 600, such as those discussed herein and provided by a pool manager and SQM. The SQM and other associated elements may provide enhanced "indirect" growable data structures, direct or indirect non-growable data structures (whether or not part of a pool), and direct growable data structures, as well as other operations and data structures.

[0096] exist Figure 6 , the first page "0" (610) includes unused data 631, which is held by the data structure 600 before being read out according to the read pointer 621. This unused data has been written into the data structure 600 and the write is confirmed, where the "write done" pointer 622 indicates the last "safe" or confirmed element that can be read. The second page "1" (611) includes further unconsumed data and a "write done" pointer 622, which indicates the location of the last confirmed write data added to the data structure 600. The portion 632 (located between 622 and 623) will be written out of order by the shader unit. In page 1, additional space 632 is included, which has been allocated for writing data that is currently being written and cannot be read out yet. The space 632 is allocated for writing but has not yet been marked as written complete. The "old allocated write pointer" 623 indicates the location for the new data to be written into the data structure 600. However, the remaining space 633 in page 1 may not be sufficient to accommodate the incoming write.

[0097] Data structure 600 is growable, so after the initial allocation of space for data structure 600, further data may be retained in data structure 600. To provide the growable functionality, a write allocation pointer may be used to point to additional pages that become allocated as needed as data is written to the data structure. Prior to adding new page "2" (612), an old write allocation pointer 623 was included in page 1 to indicate the end of the space filled with write data or the incoming write data that had been allocated to data structure 600. In response to the additional page 612 of memory being allocated for data structure 600, the write allocation pointer may point to a "new" location 624 in data structure 600, which indicates the end of the current allocation of space for data structure 600 after it has been expanded to hold more data.

[0098] Growth of data structure 600 may be triggered when a write to data structure 600 exceeds the remaining available space or a predetermined threshold amount of remaining space in data structure 600. For example, if further data is determined to not fit into Figure 6If page 1 in the free page list is read, a pointer to new page 2 may be requested from the free page list and the associated page space allocated for this further data. Data structure 600 may be shrunk or reduced in size and data is used and requires less space than before. For example, once read pointer 621 advances beyond page 0, page 0 may be released back to the free page list. Assuming that the incoming new write exceeds the available space for page 1, additional space is introduced into data structure 600 using page 2, and this space is Figure 6 633 in the data structure 600. After adding page 2 to the data structure 600, the "new write allocation pointer" 624 indicates where further writes can be stored. In response to the consumption of data in the data structure 600, pages can be removed or de-allocated from the data structure 600 and returned to the free page list for future use. In general, the "pool manager" discussed herein can use a free page list (such as, Figure 5 The ring buffer 501 discussed in ) is used to handle the allocation and deallocation of pages from the data structure 600.

[0099] also, Figure 6 Each page 0, 1, 2 in includes an associated portion 601, 602, and 603 dedicated to link list pointers that contribute to the formation of data structure 600. In this example, data structure 600 includes a linked list of pages. The linked list pointers allow the pages to be sequentially linked to successive pages. This sequential linking of pages forms the structure of data structure 600, and as data structure 600 grows, additional pages can be linked to existing pages using these pointers. Using the pointers included in Figure 5 , pointers to pages (including in portions 601, 602, and 603) are allocated and de-allocated on demand (dynamically) using the pointer information in the free page list or "ring buffer" discussed in , In one example, the first or last "n" bytes (such as 8 bytes) of a page may be reserved as portions 601, 602, and 603 to store pointers to the next page and / or previous page. Alternatively, linked list pointers may be implemented elsewhere, which allows the entire page size to be used to buffer data, rather than reserving a portion of each page as portions 601, 602, and 603. Alternatively, portions 601-603 may contain counts of outstanding reads and writes for each page (as well as a write allocation pointer for each page), which may be used to help track the write completion pointer 622, as well as to track when these pages are released. Pointers or other information included in portions 601-603 may be cached in Figure 4 The pointer or other information is typically written to the memory 464 only when the page header buffer 453 becomes full or is refreshed by the controller 413.

[0100]

[0066] Certain inventive aspects can be appreciated from the foregoing disclosure, and following are various examples of these inventive aspects.

[0101] Example 1: A method of handling data buffer resources in a graphics processor, the method comprising establishing a pool of available memory pages tracked by a memory pointer for use in a growable data structure. The method comprises, in response to a request by at least a shader unit of the graphics processor for space in the growable data structure for writing shader data, providing to the shader unit at least a write pointer to a location of a memory page in the growable data structure based on a data size indicated in the request. The method comprises, in response to exceeding a threshold fullness of the growable data structure, allocating at least one further memory page from the pool of available memory pages for inclusion in the growable data structure.

[0102] Example 2: The method of Example 1 further includes, in response to the request, processing the data size to determine whether the shader data can fit into the current page of the growable data structure. Based on the shader data not fitting into the current page, the method includes providing to the shader unit a first pointer indicating a starting position in the growable data structure for starting to write the shader data, count information indicating an amount of shader data that can be written to the current page, and a second pointer indicating at least one further page in the growable data structure into which the shader data can extend from the current page.

[0103] Example 3: The method of Examples 1-2, further comprising receiving a write completion message from a shader unit, the write completion message indicating an amount of data written to at least one further page, and responsively updating a corresponding pointer indicating the availability of the data for future read requests.

[0104] Example 4: The method of Examples 1-3, further comprising, in response to a shader unit indicating that shader data is used in one or more of the memory pages, the method comprising returning one or more of the memory pages to a pool of available memory pages.

[0105] Example 5: The method of Examples 1-4 further includes linking one or more of the memory pages to each other in a growable data structure using page pointers included in a reserved portion of each of one or more of the memory pages in each memory page, wherein the page pointers each indicate at least the next page in the growable data structure.

[0106] Example 6: The method of Examples 1-5, wherein memory pointers in the pool of available memory pages are tracked using at least one ring buffer configured to store pointers to available memory pages that are not already included in the growable data structure.

[0107] Example 7: The method of Examples 1-6 further includes retaining a write pointer in the growable data structure, the write pointer indicating a location within the growable data structure for starting a write operation on the shader data, and retaining a read pointer in the growable data structure, the read pointer indicating a location within the growable data structure for starting a read operation on the shader data.

[0108] Example 8: The method of Examples 1-7, wherein the request includes at least one combined request that groups requests for multiple shader threads for at least one thread group of the shader unit. The method also includes processing the at least one combined request to determine the requested amount of space for writing the growable data structure. Based at least on the requested amount of space, the method includes providing the shader unit with a start pointer indicating a start location in the growable data structure for starting to write shader data for the multiple shader threads, count information indicating the amount of shader data that can be written to the first page, and an additional pointer indicating at least one further page in the growable data structure into which the shader data can extend from the first page.

[0109] Example 9: The method of Example 1 further includes providing a status of the growable data structure via an outliner element configured to at least indicate a fullness status of the growable data structure, wherein scheduling of further data operations for the growable data structure is determined based on at least the fullness status.

[0110] Example 10: A data buffer management service, comprising: a pool manager configured to manage a pool of available memory pages tracked by a memory pointer for use in a buffer data structure, and a buffer manager configured to receive a write space request issued by a shader unit of a graphics processor and, based on a data size indicated in the request, responsively provide to the shader unit at least a write pointer to a location in a memory page of the buffer data structure. The pool manager is further configured to allocate at least one further memory page for inclusion in the buffer data structure in response to exceeding a threshold fullness of the buffer data structure.

[0111] Example 11: The data buffer management service of Example 10, comprising: the buffer manager is configured to process the data size indicated by the write space request to determine whether the associated shader data can be accommodated in the current page of the buffer data structure. Based on the shader data size exceeding the available space in the current page, the buffer manager is configured to provide to the shader unit a first pointer indicating a starting position in the buffer data structure for starting to write the associated shader data, count information indicating an amount of the associated shader data that can be written to the current page, and a second pointer indicating at least one further page in the buffer data structure into which the associated shader data can extend from the current page.

[0112] Example 12: The data buffer management service of Examples 10-11, comprising: the buffer manager is configured to receive a write completion message from a shader unit, the write completion message indicating the amount of data written to at least one further page, and responsively update a corresponding pointer indicating a starting position in a buffer data structure for future write space requests.

[0113] Example 13: The data buffer management service of Examples 10-12, comprising: the pool manager is configured to return one or more of the memory pages to the pool of available memory pages in response to a shader unit indicating that shader data is used in one or more of the memory pages.

[0114] Example 14: The data buffer management service of Examples 10-13, comprising: the buffer manager is configured to link one or more of the memory pages to each other in a buffer data structure using page pointers included in a reserved portion of each of one or more of each memory page, wherein the page pointers each indicate at least a next page in the buffer data structure.

[0115] Example 15: The data buffer management service of Examples 10-14, wherein memory pointers in the pool of available memory pages are tracked using at least one ring buffer configured to store pointers to available memory pages not yet contained in the buffer data structure.

[0116] Example 16: The data buffer management service of Examples 10-15, comprising: the buffer manager is configured to retain a write pointer in the buffer data structure, the write pointer indicating the location within the buffer data structure for starting a write operation on shader data, and the buffer manager is configured to retain a read pointer in the buffer data structure, the read pointer indicating the location within the buffer data structure for starting a read operation on shader data.

[0117] Example 17: The data buffer management service of Examples 10-16, wherein: the write space request includes at least one combined request that groups requests for multiple shader threads for at least one thread group of the shader unit. The buffer manager is configured to process the at least one combined request to determine the requested amount of space for writing the growable data structure. Based at least on the requested amount of space, the buffer manager is configured to provide the shader unit with a start pointer indicating a start position in the growable data structure for starting to write shader data for multiple shader threads, count information indicating the amount of shader data that can be written to the first page, and an additional pointer indicating at least one further page in the growable data structure into which the shader data can extend from the first page.

[0118] Example 18: The data buffer management service of Examples 10-17, further comprising: a buffer summarizer element, which is configured to provide a status of a buffer data structure that at least indicates a full status of the buffer data structure, wherein scheduling of further data operations for the buffer data structure is determined based on at least the full status.

[0119] Example 19: A graphics processing device, comprising: a shader unit configured to process shader data, and a buffer system configured to receive a data handling request from the shader unit and responsively provide the shader unit with a pointer to a memory page to begin storing and retrieving shader data within a growable data structure. The buffer system is further configured to increase the size of the growable data structure responsive to a fullness state of the growable data structure by obtaining a pointer to an additional memory page from at least a free page list that tracks free memory pages in a memory pool for the growable data structure, and forming a sequential link between the additional memory page and an existing memory page in an associated growable data structure using the pointer saved in at least a reserved portion of the additional memory page.

[0120] Example 20: The graphics processing device of Example 19 includes: for a write request in a data handling request, the buffer system is further configured to: provide a write pointer to the shader unit indicating a starting position in a growable data structure for starting to write associated shader data, count information indicating the amount of associated shader data that can be included in the memory page corresponding to the write pointer, and a second pointer indicating at least one additional page into which the associated shader data can be extended.

[0121] The functional block diagrams, operation scenarios and sequences and flow charts provided in the accompanying drawings represent exemplary systems, environments and methods for executing the novel aspects of the present disclosure. Although for the purpose of explaining concisely, the methods included herein can be shown in the form of functional diagrams, operation scenarios or sequences, or flow charts and can be described as a series of actions, it can be understood and appreciated that each method is not limited by the order of these actions, because according to the present invention, some actions can occur in a different order from that shown and described herein and / or concurrently with other actions. For example, those skilled in the art will understand and appreciate that the method can be alternatively represented as a series of mutually related states or events, such as in the form of a state diagram. In addition, not all actions shown in the method are necessary for novel implementation.

[0122] The description and drawings included herein depict specific implementations for teaching those skilled in the art how to make and use the best options. For the purpose of teaching creative principles, some traditional aspects have been simplified or omitted. Those skilled in the art will appreciate that variations from these implementations also fall within the scope of the present disclosure. Those skilled in the art will also appreciate that the various features described above can be combined in various ways to form multiple implementations. As a result, the present invention is not limited to the specific implementations described above, but is only limited by the claims and their equivalents.

Claims

1. A method for handling data buffer resources in a graphics processor, the method comprising: establishing a pool of available memory pages tracked by a memory pointer for use in a data structure; processing requests for storing data in the data structure to identify one or more requests in the requests indicating a size of data that exceeds a capacity of a current page included in the data structure; In response to one or more of the requests, a first pointer is provided indicating a starting position in the data structure for starting to write associated data, count information indicating an amount of the associated data that can be written to the current page, and a second pointer indicates at least one additional page in the data structure into which the associated data can extend from the current page, wherein the at least one additional page is allocated from the pool of available memory pages for inclusion in the data structure based on a fullness threshold of the data structure.

2. The method of claim 1, further comprising: A write completion message is received indicating an amount of data written to the at least one additional page, and a corresponding pointer is responsively updated indicating the availability of the data for a subsequent read request.

3. The method of claim 1, further comprising: In response to an indication that the data is used in one or more memory pages forming the data structure, the one or more memory pages are returned to the pool of available memory pages.

4. The method of claim 1, further comprising: The memory pages forming the data structure are linked to each other in the data structure using page pointers included in a reserved portion of each of the memory pages, wherein the page pointers each indicate at least a next page in the data structure.

5. The method according to claim 1, characterized in that The memory pointers in the pool of available memory pages are tracked using at least one ring buffer configured to store pointers to the available memory pages not contained in the data structure.

6. The method of claim 1, further comprising: retaining a write pointer in the data structure, the write pointer indicating a location within the data structure for starting a write operation on the data; as well as A read pointer is maintained in the data structure, the read pointer indicating a location within the data structure for beginning a read operation on the data.

7. The method according to claim 1, characterized in that The request is issued by at least a shader unit of a graphics processor for a space in the data structure where shader data is to be written.

8. The method according to claim 7, characterized in that The requests include at least one combined request that groups requests for a plurality of shader threads of at least one thread group of the shader unit, and the method further includes: processing the at least one combined request to determine a requested amount of space for writing the data structure; and Based at least on the requested amount of space, providing to the shader unit a start pointer indicating a starting location in the data structure for starting to write data for the multiple shader threads, count information indicating an amount of the data that can be written to the first page, and an additional pointer indicating at least one second page in the data structure into which the data can extend from the first page.

9. The method of claim 1, further comprising: The status of the data structure is provided by a summarizer element configured to indicate at least a fullness status of the data structure, wherein scheduling of further data operations for the data structure is determined based on at least the fullness status.

10. A data buffer system, comprising: a pool manager configured to establish a pool of available memory pages tracked by memory pointers for use in data structures; a buffer manager configured to process requests for storing data in the data structure to identify one or more of the requests indicating a size of data that exceeds a capacity of a current page included in the data structure; In response to one or more of the requests, the buffer manager is configured to provide a first pointer indicating a starting position in the data structure for starting to write the associated data, count information indicating an amount of the associated data that can be written to the current page, and a second pointer indicating at least one additional page in the data structure into which the associated data can extend from the current page, wherein the at least one additional page is allocated by the pool manager from the pool of available memory pages for inclusion in the data structure based on a fullness threshold of the data structure.

11. The data buffer system of claim 10, comprising: The buffer manager is configured to receive a write completion message indicating an amount of data written to the at least one additional page and responsively update a corresponding pointer indicating availability of the data for a subsequent read request.

12. The data buffer system of claim 10, comprising: In response to an indication that the data is used in one or more memory pages forming the data structure, the pool manager is configured to return the one or more memory pages to the pool of available memory pages.

13. The data buffer system of claim 10, comprising: The buffer manager is configured to link the memory pages forming the data structure to each other in the data structure using page pointers included in a reserved portion of each of the memory pages, wherein the page pointers each indicate at least a next page in the data structure.

14. The data buffer system according to claim 10, wherein: The memory pointers in the pool of available memory pages are tracked using at least one ring buffer configured to store pointers to the available memory pages not contained in the data structure.

15. The data buffer system of claim 10, comprising: The buffer manager is configured to retain a write pointer in the data structure, the write pointer indicating a location within the data structure for starting a write operation on the data; as well as The buffer manager is configured to maintain a read pointer in the data structure, the read pointer indicating a location within the data structure for starting a read operation on the data.

16. The data buffer system of claim 10, wherein: The request is issued by at least a shader unit of a graphics processor for a space in the data structure where shader data is to be written.

17. The data buffer system of claim 16, wherein: The requests include at least one combined request that groups requests for a plurality of shader threads of at least one thread group of the shader unit, and further include: The buffer manager is configured to process the at least one combined request to determine a requested amount of space for writing the data structure; and Based at least on the requested amount of space, the buffer manager is configured to provide to the shader unit a start pointer indicating a starting location in the data structure for starting to write data for the multiple shader threads, count information indicating an amount of the data that can be written to the first page, and an additional pointer indicating at least one second page in the data structure into which the data can extend from the first page.

18. The data buffer system of claim 10, further comprising: A summarizer element is configured to provide a status of the data structure to indicate at least a fullness status of the data structure, wherein scheduling of further data operations for the data structure is determined based on at least the fullness status.

19. An apparatus comprising: one or more computer-readable storage media; a processing system operatively coupled to the one or more computer-readable storage media; as well as The program instructions stored on the one or more computer-readable storage media, upon being read and executed by the processing system, direct the processing system to at least: establishing a pool of available memory pages tracked by a memory pointer for use in a data structure; processing requests for storing data in the data structure to identify one or more requests in the requests indicating a size of data that exceeds a capacity of a current page included in the data structure; In response to one or more of the requests, a first pointer is provided indicating a starting location in the data structure for starting to write associated data, count information indicating an amount of the associated data that can be written to the current page, and a second pointer indicating at least one additional page in the data structure into which the associated data can extend from the current page, wherein the at least one additional page is allocated from the pool of available memory pages for inclusion in the data structure based on a fullness threshold of the data structure.

20. The apparatus of claim 19, comprising further program instructions that upon being executed by the processing system direct the processing system to at least: The memory pages forming the data structure are linked to each other in the data structure using page pointers included in a reserved portion of each of the memory pages, wherein the page pointers each indicate at least a next page in the data structure.

Images