US-12620160-B2 - Graphics library extensions

Abstract

A system and method for performing graphics processing is provided. The system and method includes processing an allocation command for a buffer object; reserving processor address space for a data store of the buffer object with uncommitted physical memory in response to the allocation command including a null parameter, and reserving processor address space for a data store of the buffer object with committed physical memory in response to the allocation command including a non-null parameter.

Inventors

• Graham Sellers
• Eric Zolnowski
• Pierre Boudier
• Juraj Obert

Assignees

• ADVANCED MICRO DEVICES, INC.

Dates

Publication Date

20260505

Application Date

20230519

Claims (20)

1. 1 . A method for graphics processing, comprising: processing an allocation command for a buffer object, wherein the buffer object is a representation of a data store, the allocation command reserving processor address space for the data store as a sparse data store with physical memory uncommitted; and processing a page commitment command for the buffer object that specifies a range of the data store and includes an indicator of commitment state, wherein processing the page commitment command sets a commitment state of physical memory for the specified range according to the indicator.
2. 2 . The method of claim 1 , wherein the allocation command includes a size of the data store of the buffer object.
3. 3 . The method of claim 1 , wherein the allocation command includes an indicator of sparse allocation of the data store.
4. 4 . The method of claim 1 , wherein the page commitment command indicates a range that is aligned to integer multiples of the memory page size.
5. 5 . The method of claim 4 , wherein the page commitment command specifies an offset that is an integer multiple of the page size of individual memory pages.
6. 6 . The method of claim 1 , further comprising: processing a initialization command to initialize the data store of the buffer object, wherein the initialization command replaces a portion of the data store of the buffer object in a range of processor address space.
7. 7 . The method of claim 6 , wherein when the range of the initialization command includes uncommitted pages, the initialization command discards data for the pages and leaves the commitment state of the pages unchanged.
8. 8 . The method of claim 6 , further comprising: issuing the page commitment command for the range of the initialization command to set the commitment state of physical memory for the range according to the indicator of commitment state.
9. 9 . The method of claim 6 , wherein the initialization command includes a data parameter, a size the portion of the data store being replaced, and an offset into the data store.
10. 10 . The method of claim 1 , wherein the buffer object includes any one or a combination of texture data or vertex data.
11. 11 . The method of claim 1 , wherein, the commitment state is committed when the indicator denotes commit.
12. 12 . The method of claim 1 , wherein the commitment state is uncommitted when the indicator denotes decommit.
13. 13 . A system, comprising: a memory configured to store instructions comprising an allocation command for a buffer object, wherein the buffer object is a representation of a data store, the allocation command reserving processor address space for the data store as a sparse data store with physical memory uncommitted; and a processor configured to process a page commitment command for the buffer object that specifies a range of the data store and includes an indicator of commitment state, wherein processing the page commitment command sets a commitment state of physical memory for the specified range according to the indicator.
14. 14 . The system of claim 13 , wherein the allocation command includes a size of the data store of the buffer object.
15. 15 . The system of claim 13 , wherein the allocation command includes an indicator of sparse allocation of the data store.
16. 16 . The system of claim 13 , wherein the page commitment command indicates a range that is aligned to integer multiples of the memory page size.
17. 17 . The system of claim 16 , wherein the page commitment command specifies an offset that is an integer multiple of the page size of individual memory pages.
18. 18 . The system of claim 13 , wherein the processor is further configured to: process an initialization command to initialize the data store of the buffer object, wherein the initialization command replaces a portion of the data store of the buffer object in a range of processor address space.
19. 19 . The system of claim 18 , wherein when the range of the initialization command includes uncommitted pages, the initialization command discards data for the pages and leaves the commitment state of the pages unchanged.
20. 20 . The system of claim 18 , wherein the processor is further configured to issue the page commitment command for the range of the initialization command to set the commitment state of physical memory for the range according to the indicator of commitment state.

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application is a continuation of U.S. patent application Ser. No. 16/915,340, filed Jun. 29, 2020, which is a continuation of U.S. patent application Ser. No. 15/339,860, filed Oct. 31, 2016, which issued on Jun. 30, 2020 as U.S. Pat. No. 10,699,464, which is a continuation of U.S. patent application Ser. No. 13/912,946, filed Jun. 7, 2013, which issued on Jul. 10, 2018 as U.S. Pat. No. 10,019,829, which claims the benefit of U.S. Provisional Application No. 61/657,290 filed Jun. 8, 2012, the contents of which are hereby incorporated by reference herein. TECHNICAL FIELD The disclosed embodiments are generally directed to processing, and in particular, to graphics processing. BACKGROUND OpenGL® is a 2D and 3D graphics application programming interface (API). It enables developers of software to create high-performance, visually compelling graphics software applications and exposes all the features of the latest graphics hardware. OpenGL® Extensions are a formal method for exposing new functionality without a major API update. It allows hardware vendors to innovate without relying on a third party, provides a path from experimental feature to fully ratified industry standard and allows software developers to leverage new features without major overhaul. SUMMARY OF EMBODIMENTS OF THE INVENTION Methods for enabling graphics features in processors are described herein. Methods are provided to enable trinary built-in functions in the shader, allow separation of the graphics processor's address space from the requirement that all textures must be physically backed, enable use of a sparse buffer allocated in virtual memory, allow a reference value used for stencil test to be generated and exported from a fragment shader, provide support for use specific operations in the stencil buffers, allow capture of multiple transform feedback streams, allow any combination of streams for rasterization, allow a same set of primitives to be used with multiple transform feedback streams as with a single stream, allow rendering to be directed to layered framebuffer attachments with only a vertex and fragment shader present, allow geometry to be directed to one of an array of several independent viewport rectangles without a geometry shader and define an interface that allows improved control of the physical memory used by the graphics device. BRIEF DESCRIPTION OF THE DRAWINGS A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein: FIG. 1 is a block diagram of an example device in which one or more disclosed embodiments may be implemented; FIG. 2 is another block diagram of an example device in which one or more disclosed embodiments may be implemented; and FIG. 3 is an example rendering pipeline in which one or more disclosed embodiments may be implemented. DETAILED DESCRIPTION Methods for enabling graphics features in processors are described herein. Methods are provided to enable trinary built-in functions in the shader, allow separation of the graphics processor's address space from the requirement that all textures must be physically backed, enable use of a sparse buffer allocated in virtual memory, allow a reference value used for stencil test to be generated and exported from a fragment shader, provide support for use specific operations in the stencil buffers, allow capture of multiple transform feedback streams, allow any combination of streams for rasterization, allow a same set of primitives to be used with multiple transform feedback streams as with a single stream, allow rendering to be directed to layered framebuffer attachments with only a vertex and fragment shader present, allow geometry to be directed to one of an array of several independent viewport rectangles without a geometry shader and define an interface that allows improved control of the physical memory used by the graphics device. FIG. 1 is a block diagram of an example device 100 in which one or more disclosed embodiments may be implemented. The device 100 may include, for example, a computer, a gaming device, a handheld device, a set-top box, a television, a mobile phone, or a tablet computer. The device 100 includes a processor 102, a memory 104, a storage 106, one or more input devices 108, and one or more output devices 110. The device 100 may also optionally include an input driver 112 and an output driver 114. It is understood that the device 100 may include additional components not shown in FIG. 1. The processor 102 may include a central processing unit (CPU), a graphics processing unit (GPU), a CPU and GPU located on the same die, or one or more processor cores, wherein each processor core may be a CPU or a GPU. The memory 104 may be located on the same die as the processor 102, or may be located separately from the processor 102. The memory 104 may include a volatile or non-volatile memory, for example,