DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
1. The information disclosure statements (IDS) submitted on 2/3/2025 and 2/13/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements have been considered by the examiner.
Drawings
2. The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because reference character “204” has been used to designate both "block 204" ([0047], line 5; [0072], line 2) and "shader cor ([0056], line 6). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Rejections - 35 USC § 103
3. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
4. Claims 1-2 and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Jin et al. (US-2018/0033184-A1, hereinafter "Jin") in view of Akenine-Moller et al. (US-2018/0082464-A1, hereinafter "Akenine-Moller").
5. As per claim 1, Jin discloses: A method of operating a graphics processing unit (GPU), the GPU comprising a shader core, vertex buffer and geometry pipeline, the method comprising, in the shader core: (Jin, [0014], “The processor 102 includes 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.” and [0011], “A software module, such as a just-in-time compiler component of a driver being executed by a host CPU, automatically generates the shader programs based on a vertex shader program that is provided for use in the vertex shader stage of the graphics processing pipeline. As is generally known, the vertex shader stage of the graphics processing pipeline may involve execution of a vertex shader program to transform vertex coordinates and to modify or generate other attributes of the vertices as needed.”)
fetching input attributes used in executing a first part of a geometry task, wherein the first part of the task executes a first part of a shader to calculate position data for each instance of the task; (Jin, [0011], “A software module, such as a just-in-time compiler component of a driver being executed by a host CPU, automatically generates the shader programs based on a vertex shader program that is provided for use in the vertex shader stage of the graphics processing pipeline. ... The automatically generated shader programs include instructions from the vertex shader program that transform the positions of vertices provided as input to the graphics processing pipeline to generate transformed input vertices.” and [0047], “The driver 122 generates the instructions of the transform shader program 430, such as the transform operations 434, based on the vertex shader program 402, by eliminating instructions of the vertex shader program 402 that contribute only to non-position attributes of vertices.” and [0061], “At step 504, the driver 122 generates a transform shader program that is configured to transform input vertex positions received for processing by the graphics processing pipeline to produce output vertex positions. The driver 122 generates the transform shader program based on the received vertex shader program. For example, the driver 122 removes instructions that are related only to non-position attribute transforms.” and [0038]-[0039], “FIG. 4 is a block diagram that illustrates automatically generated compute shaders for pre-graphics-pipeline culling. The driver 122 generates a cull shader program 410 and a transform shader program 430, and, optionally, a fetch shader program 420, based on a vertex shader program 402 that is provided to the driver 122 for execution at the vertex shader stage 304. The cull shader program 410, optional fetch shader program 420, and transform shader program 430 include instructions for performing the position transforms of the provided vertex shader program 402 and for culling primitives based on the vertices transformed by such position transforms. The cull shader program 410 acts as a “main” shader program, calling the fetch shader program 420 or transform shader program 430 to perform subordinate functionality as indicated herein.” and [0051], “In some alternatives, the vertex shader program 402 is modified to receive inputs from the outputs of the automatically generated shader programs, and/or in line with other modifications described herein such as to use transformed vertex positions generated by the automatically generated shader programs.”)
executing the first part of the task; (Jin, [0011]-[0012], “The automatically generated shader programs include instructions from the vertex shader program that transform the positions of vertices provided as input to the graphics processing pipeline to generate transformed input vertices. The shader programs also include instructions to cull primitives based on the transformed input vertices. The shader programs do not, however, include instructions for transforming or generating non-position attributes of input vertices, because the output of these instructions are not used by the culling instructions. After generating the automatically generated shader programs, the software module transmits the automatically generated shader programs to the graphics processing pipeline for execution.” and [0039], “The cull shader program 410 ... include instructions for performing the position transforms of the provided vertex shader program 402 and for culling primitives based on the vertices transformed by such position transforms. The cull shader program 410 acts as a “main” shader program ...”)
outputting the position data for each instance of the task; (Jin, [0061], “At step 504, the driver 122 generates a transform shader program that is configured to transform input vertex positions received for processing by the graphics processing pipeline to produce output vertex positions. The driver 122 generates the transform shader program based on the received vertex shader program. For example, the driver 122 removes instructions that are related only to non-position attribute transforms.”)
[[descheduling the task until cull results are received for each instance of the task; and]]
in response to receiving cull results [[indicating at least one remaining instance in the task that has not been culled:]] (Jin, [0064], “The cull shader program is also configured to write the results of the culling operations into one or more buffers to be read by the vertex shader stage 304 of the graphics processing pipeline 134 while the graphics processing pipeline 134 is processing primitives for rendering.” and [0069], “A customized fetch shader for the vertex shader stage 304 of the graphics processing pipeline 134 may exist and may be configured to read from the buffer that stores the culled primitives ...”)
fetching input attributes used in executing a second part of a task, wherein the second part of the task executes a second part of a shader to calculate varyings for each remaining instance of the task, executing the second part of the task, and outputting the varyings for each remaining instance of the task. (Jin, [0073], “Although the vertex shader program that executes at the vertex shader stage 304 of the graphics processing pipeline 134 is described as not being modified herein, in one alternative, the vertex shader stage 304 is modified to use the transformed vertices from the generated shaders executed at the compute stage instead of re-computing the transforms for those vertices. The vertex shader program would still compute transforms for non-position attributes. The driver 122 could use dead code elimination to remove instructions that only contribute to position transforms and could also modify the vertex shader programs to simply pass through the already transformed vertex positions, accepting such transformed positions as input and transmitting the transformed vertex positions out as output.” and [0051], “In some alternatives, the vertex shader program 402 is modified to receive inputs from the outputs of the automatically generated shader programs, and/or in line with other modifications described herein such as to use transformed vertex positions generated by the automatically generated shader programs.” and [0037], “Such vertex shader programs also define instructions for performing operations to modify or generate non-position attributes for vertices, such as values that define vertex lighting, color, texture coordinates, or any other aspect of vertices that do not define position of the vertices within rendering space.” and [0002], “The graphics processing pipeline processes these primitives elements to generate transformed primitives elements (e.g., via a vertex shader), and then processes the transformed primitive elements (e.g., via a pixel shader) to generate pixels for output to the screen.”; Examiner’s note: As disclosed by Jin in [0073] and [0037], either a modified or unmodified vertex shader program would be run in order to “compute transforms for non-position attributes” “such as values that define vertex lighting, color, texture coordinates.” As disclosed in [0002], these computed transforms are then sent from the vertex shader to the pixel shader to be processed, which one of ordinal skill in the art would understand as varyings.)
6. Jin doesn't explicitly disclose but Akenine-Moller discloses: descheduling the task until cull results are received for each instance of the task; and (Akenine-Moller, [0129], “In particular, this embodiment uses a “repeat token” to identify one or more sequences of draw calls that will produce the exact same set of triangles. The GPU will record culling data during the first occurrence of the token, or use the recorded data during subsequent occurrences of the same token. Triangles or groups of triangles or entire draw calls that were culled during recording can be skipped in the subsequent occurrences.” and [0132], “As illustrated in FIG. 18, one embodiment of the invention stores the results 1812 of Clipping & Culling module 1703, and associates the results with a replay token. When the same token is used again, the stored culling data 1812 is used to remove culled triangles during Input assembly 1701, thus lowering the burden on the vertex shader 1702 and Clipping & Culling module 1703, and lowering bandwidth usage of vertex data. In one embodiment, the culling data 1812 is disposed of when the application destroys the associated replay token.” and [0134], “The embodiments of the invention associate the generated culling data 1812 with a replay token and retains the culling data until the associated replay token is destroyed by the application. When the replay token is encountered again, the cull pipe is not executed, and the render pipe uses the same associated culling data again.”; Examiner’s note: As disclosed by Akenine-Moller in [0129], the “embodiment uses a “repeat token” to identify one or more sequences of draw calls that will produce the exact same set of triangles” and “The GPU will record culling data during the first occurrence of the token, or use the recorded data during subsequent occurrences of the same token.” The phrase “during the first occurrence of the token, or … subsequent occurrences of the same token” indicates there is a period of time between occurrences of the token and thus would indicate time where draw calls related to the task are “descheduled” and not occurring. Finally, as disclosed in [0134], “When the replay token is encountered again … the render pipe uses the same associated culling data again.” which indicates that upon encountering the token again, the task is re-enabled for a full render pass.)
[[in response to receiving cull results]] indicating at least one remaining instance in the task that has not been culled: (Akenine-Moller, [0134], “The embodiments of the invention associate the generated culling data 1812 with a replay token and retains the culling data until the associated replay token is destroyed by the application. When the replay token is encountered again, the cull pipe is not executed, and the render pipe uses the same associated culling data again.” and [0132], “As illustrated in FIG. 18, one embodiment of the invention stores the results 1812 of Clipping & Culling module 1703, and associates the results with a replay token. When the same token is used again, the stored culling data 1812 is used to remove culled triangles during Input assembly 1701, thus lowering the burden on the vertex shader 1702 and Clipping & Culling module 1703, and lowering bandwidth usage of vertex data. In one embodiment, the culling data 1812 is disposed of when the application destroys the associated replay token.”)
7. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of Jin to include the disclosure of descheduling the task until cull results are received for each instance of the task and indicating at least one remaining instance in the task that has not been culled, of Akenine-Moller. The motivation for this modification could have been to decrease resources by descheduling tasks while the cull process is ongoing. In addition, by keeping track of the culling process, this helps determine which aspects of the task still need to complete so that varyings can be properly output for all the tasks.
8. As per claim 2, Jin in view of Akenine-Moller discloses: The method according to claim 1, further comprising, in the vertex buffer:
storing the position data for the task; (Jin, [0043], “After the primitive culling instructions 416, the cull shader program 410 performs write ring buffers instructions 418. The ring buffers referred to herein are buffers that include vertex data and indices for consumption by the graphics processing pipeline 134.”)
kicking the position data for the task into a front-end of the geometry pipeline; and (Jin, [0011], “The automatically generated shader programs include instructions from the vertex shader program that transform the positions of vertices provided as input to the graphics processing pipeline to generate transformed input vertices.” and [0012], “After generating the automatically generated shader programs, the software module transmits the automatically generated shader programs to the graphics processing pipeline for execution. These shader programs process primitives received from the host CPU for processing by the graphics processing pipeline and thus act as a sort of “front end filter” for the graphics pipeline.” and [0033]-[0034], “A pre-processing compute shader stage 330 is coupled to the graphics processing pipeline 134. The pre-processing compute shader stage 330 allows computational work to be performed on primitives received from outside of the APD 116 (e.g., from the processor 102) before being processed by the graphics processing pipeline 134. ... These pre-processing compute shader programs accept specified inputs, such as primitives or vertices, and produce specified outputs, such as modified primitives or vertices. ... One use for the pre-processing compute shader stage 330 is to perform culling.”)
in response to receiving cull results for the task from the front-end of the geometry pipeline, providing the cull results to the shader core. (Jin, [0012], “After generating the automatically generated shader programs, the software module transmits the automatically generated shader programs to the graphics processing pipeline for execution. These shader programs process primitives received from the host CPU for processing by the graphics processing pipeline and thus act as a sort of “front end filter” for the graphics pipeline. After culling primitives, the automatically generated shader programs output culled primitives to the remainder of the graphics processing pipeline. The graphics processing pipeline thus avoids processing primitives that are culled by the shader programs, reducing the amount of work to be performed by the graphics processing pipeline and improving performance of the graphics processing pipeline.” and [0064], “The cull shader program is also configured to write the results of the culling operations into one or more buffers to be read by the vertex shader stage 304 of the graphics processing pipeline 134 while the graphics processing pipeline 134 is processing primitives for rendering.” and [0069], “A customized fetch shader for the vertex shader stage 304 of the graphics processing pipeline 134 may exist and may be configured to read from the buffer that stores the culled primitives ...”)
9. Claim 14, which is similar in scope to independent claim 1, is thus rejected under the same rationale as described above. The motivation for this modification is the same as claim 1.
10. Claim 15, which is similar in scope to dependent claim 2 and independent claim 14, is thus rejected under the same rationale as described above. The motivation for this modification is the same as claim 2.
11. Claims 3 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Jin et al. (US-2018/0033184-A1, hereinafter "Jin") in view of Akenine-Moller et al. (US-2018/0082464-A1, hereinafter "Akenine-Moller"), and further in view of Sideris et al. (US-2023/0062386-A1, hereinafter "Sideris").
12. As per claim 3, Jin in view of Akenine-Moller discloses: The method according to claim 1, further comprising, in the shader core:
in response to receiving cull results [[indicating all instances in the task have been culled, terminating the task.]] (See rejection for claim 1.)
13. Jin in view of Akenine-Moller doesn't explicitly disclose but Sideris discloses: [[in response to receiving cull results]] indicating all instances in the task have been culled, terminating the task.
(Sideris, [0095], “Thus, in an embodiment, the execution unit is part of a fragment shader and the fragment shader is part of an overall graphics processing pipeline that includes one or more forward fragment culling stages that are capable of killing fragments that are further ahead in the graphics processing pipeline. That is, in embodiments, the graphics processing program that is performed by the execution unit corresponds to a fragment shader program that is being executed as part of a graphics processing pipeline, wherein individual execution threads process respective fragments, and wherein the event that means that a subset of one or more execution threads should be terminated corresponds to a fragment culling operation from another stage in the graphics processing pipeline, the fragment culling operation indicating that a respective one or more fragment(s) can be culled, and thereby indicating that the corresponding execution threads for the one or more fragment(s) to be culled should be terminated.”)
14. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 1 of Jin in view of Akenine-Moller to include the disclosure of indicating all instances in the task have been culled, terminating the task, of Sideris. The motivation for this modification could have been to save computing resources by immediately terminating a task when all instances have been culled.
15. Claim 16, which is similar in scope to dependent claim 3 and independent claim 14, is thus rejected under the same rationale as described above. The motivation for this modification is the same as claim 3.
16. Claims 4 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Jin et al. (US-2018/0033184-A1, hereinafter "Jin") in view of Akenine-Moller et al. (US-2018/0082464-A1, hereinafter "Akenine-Moller"), and further in view of Øygard et al. (EP-4411651-A1, hereinafter "Øygard").
17. As per claim 4, Jin in view of Akenine-Moller discloses: The method according to claim 1, further comprising, in response to receiving cull results indicating at least one remaining instance in the task that has not been culled, in the vertex buffer: (See rejection for claim 1.)
[[storing the varyings for the task; and]]
[[kicking the varyings for the task into a back-end of the geometry pipeline.]]
18. Jin in view of Akenine-Moller doesn't explicitly disclose but Øygard discloses: storing the varyings for the task; and (Øygard, [0095], “In some embodiments, the vertex position attributes may be processed (shaded) in advance, e.g. during an initial geometry processing stage, and then fetched in from (external) memory during the rendering stage. In that case, when the first, pre-pass operation only requires vertex position attributes, there is then no need to perform any vertex processing (shading) during the first, pre-pass operation, and the vertex processing in the first, pre-pass operation may simply comprise reading in the relevant vertex position attributes. For primitives that are to be processed further by the second, main pass operation (i.e. primitives that are not culled in their entirety before the vertex processing stage in the second, main pass operation), the second, main pass operation should then (and does) process the other, non-position (varyings) attributes for the primitive vertices accordingly, and perform an appropriate allocation in vertex storage for the non-position (varyings) attributes to be written to.”)
kicking the varyings for the task into a back-end of the geometry pipeline. (Øygard, [0101], “For example, in a first such embodiment, in the situation where the first, pre-pass operation only processes the vertex position attributes (such that the processing of any other, non-position (varyings) attributes is omitted by the first, pre-pass operation), the first, pre-pass operation may again allocate only enough space in the vertex storage for the shaded vertex position attributes (data). However, in this embodiment, the second, main pass operation only processes the non-position (varyings) attributes that were not processed already by the first, pre-pass operation. Thus, rather than the second, main pass making a new allocation for the entire set of vertex attributes, the second, main pass operation only allocates space for the non-position (varyings) attributes.” and [0379], “The vertex shader execution typically produces (transformed) vertex positions and one or more outputs explicitly written by the vertex shader. Attributes communicated from the vertex shader to rasterisation and rendering other than position are usually referred to as "varyings". (Thus the non-position outputs from the vertex shader (and only the non-position outputs from the vertex shader) are "varyings".)) Once the vertex attributes have been shaded, the "shaded" attributes are then used when processing the vertices (and the primitives to which they relate) in the remainder of the graphics processing pipeline.” and [0173], “Thus, when the graphics processor is in a first, pre-pass state, the graphics processing pipeline of the rendering circuit is configured to perform a first set of processing operations to perform the first, pre-pass operation, whereas when the graphics processor is in a second, main pass state, the (same) graphics processing pipeline of the rendering circuit is configured differently to perform a second set of processing operations to perform the second, main pass operation. Correspondingly, the graphics processor may also exist in a third, fallback state, in which the graphics processing pipeline of the rendering circuit is configured (differently again) to perform a third set of processing operations to perform the third, fallback operation.”)
19. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 1 of Jin in view of Akenine-Moller to include the disclosure of storing the varyings for the task and kicking the varyings for the task into a back-end of the geometry pipeline, of Øygard. The motivation for this modification could have been to provide storage for output varyings for when they are referenced later. This helps prevent recalculating the varyings again and only requires a data lookup when the varyings are needed later in the pipeline.
20. Claim 17, which is similar in scope to dependent claim 4 and independent claim 14, is thus rejected under the same rationale as described above. The motivation for this modification is the same as claim 4.
21. Claims 5-6, 8-9, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Jin et al. (US-2018/0033184-A1, hereinafter "Jin") in view of Akenine-Moller et al. (US-2018/0082464-A1, hereinafter "Akenine-Moller"), further in view of Øygard et al. (EP-4411651-A1, hereinafter "Øygard"), and further in view of Zhao et al. (US-2016/0035128-A1, hereinafter "Zhao").
22. As per claim 5, Jin in view of Akenine-Moller, and further in view of Øygard discloses: The method according to claim 4, further comprising: (See rejection for claim 4.)
[[allocating a region of off-chip storage to a geometry task on creation of the geometry task, receiving, at the vertex buffer, a memory allocation request for the geometry task from the shader core, wherein the memory allocation request is received after generation of the position data; and]]
[[in response to receiving the memory allocation request, determining, by the vertex buffer, whether to allocate a region of the vertex buffer to the geometry task;]]
[[wherein in response to allocating the region of the vertex buffer, the position data and varyings are written to the vertex buffer and in response to determining not to allocate the region of the vertex buffer, the position data and varyings are written to the allocated region of off-chip storage.]]
23. Jin in view of Akenine-Moller, and further in view of Øygard doesn't explicitly disclose but Zhao discloses: allocating a region of off-chip storage to a geometry task on creation of the geometry task, receiving, at the vertex buffer, a memory allocation request for the geometry task from the shader core, wherein the memory allocation request is received after generation of the position data; and (Zhao, [0022], “Specifically, concerning each primitive having vertices processed by the preceding vertex position shader 112 and required to be processed by the following pixel shader 104, the binning module 103 checks distribution of the primitive in the screen space to find out bin(s) covered by the primitive, and stores primitive information of the primitive into a table (or a list) in the first storage device 106 (e.g., an off-chip bin memory).” and [0035], “With regard to the COV buffer 310 shown in FIG. 3, it is a fixed-size buffer allocated in the bin memory 300, and is used to buffer varying data (i.e., vertex attribute shading results) of in-tile vertices generated from the vertex attribute shader 114 when an overflow condition of the second storage device 110 is met. When the COV buffer 310 is not full yet, a free space is allocated in the COV buffer 310 for buffering the overflowed varying data. In addition, a vertex pointer in VPB 302 is set to point to this allocated space in COV buffer 310. ... Though the COV buffer 310 is allocated in the off-chip bin memory, the COV buffer 310 is implemented using a fixed-size buffer, which is beneficial for bin memory size control.” and [0031], “The binning result generated by the binning module 103 and the classification result generated by the vertex classification module 102 are stored into the first storage device 106. In one exemplary design, the first storage device 106 may be implemented using a bin memory 300 shown in FIG. 3. The bin memory 300 may be an off-chip dynamic random access memory (DRAM), and may include a vertex position buffer (VPB) 302, a vertex flag buffer (VFB) 304, a vertex varying buffer (VVB) 306, a bin buffer 308, a circular overflow (COV) buffer, and miscellaneous buffers (not shown).”)
in response to receiving the memory allocation request, determining, by the vertex buffer, whether to allocate a region of the vertex buffer to the geometry task; (Zhao, [0035], “With regard to the COV buffer 310 shown in FIG. 3, it is a fixed-size buffer allocated in the bin memory 300, and is used to buffer varying data (i.e., vertex attribute shading results) of in-tile vertices generated from the vertex attribute shader 114 when an overflow condition of the second storage device 110 is met. When the COV buffer 310 is not full yet, a free space is allocated in the COV buffer 310 for buffering the overflowed varying data. … When the COV buffer 310 is full, the COV buffer 310 will stall until any free space becomes available due to a stored vertex attribute shading result of an in-tile vertex data being referenced by the pixel shader 104. In this embodiment, the second storage device 110 may be implemented using an on-chip cache. The vertex attribute shading results of in-tile vertices are not kept in the VVB 306, but may be kept in the second storage device 110 (if the overflow condition is not met) or the COV buffer 310 (if the overflow condition is met). In other words, the priority of writing vertex attribute shading results of in-tile vertices into the on-chip cache is higher than the priority of writing vertex attribute shading results of in-tile vertices into a fixed-size buffer allocated in an off-chip bin memory. Though the COV buffer 310 is allocated in the off-chip bin memory, the COV buffer 310 is implemented using a fixed-size buffer, which is beneficial for bin memory size control.”)
wherein in response to allocating the region of the vertex buffer, the position data and varyings are written to the vertex buffer and in response to determining not to allocate the region of the vertex buffer, the position data and varyings are written to the allocated region of off-chip storage. (Zhao, [0040], “The vertex attribute shader 114 applies different storage strategies to vertex attribute shading results (i.e., varying data) of the in-tile vertices and vertex attribute shading results (i.e., varying data) of the out-tile vertices. Specifically, the vertex attribute shading results (i.e., varying data) of at least a portion (i.e., part or all) of the in-tile vertices processed by the vertex attribute shader 114 are stored in the second storage device (e.g., on-chip cache) 110 only, while the vertex attribute shading results (i.e., varying data) of all out-tile vertices processed by the vertex attribute shader 114 will be eventually written into the first storage device (e.g., off-chip bin memory) 106.” and [0035], “With regard to the COV buffer 310 shown in FIG. 3, it is a fixed-size buffer allocated in the bin memory 300, and is used to buffer varying data (i.e., vertex attribute shading results) of in-tile vertices generated from the vertex attribute shader 114 when an overflow condition of the second storage device 110 is met. When the COV buffer 310 is not full yet, a free space is allocated in the COV buffer 310 for buffering the overflowed varying data. … When the COV buffer 310 is full, the COV buffer 310 will stall until any free space becomes available due to a stored vertex attribute shading result of an in-tile vertex data being referenced by the pixel shader 104. In this embodiment, the second storage device 110 may be implemented using an on-chip cache. The vertex attribute shading results of in-tile vertices are not kept in the VVB 306, but may be kept in the second storage device 110 (if the overflow condition is not met) or the COV buffer 310 (if the overflow condition is met). In other words, the priority of writing vertex attribute shading results of in-tile vertices into the on-chip cache is higher than the priority of writing vertex attribute shading results of in-tile vertices into a fixed-size buffer allocated in an off-chip bin memory. Though the COV buffer 310 is allocated in the off-chip bin memory, the COV buffer 310 is implemented using a fixed-size buffer, which is beneficial for bin memory size control.” and [0031], “The binning result generated by the binning module 103 and the classification result generated by the vertex classification module 102 are stored into the first storage device 106. In one exemplary design, the first storage device 106 may be implemented using a bin memory 300 shown in FIG. 3. The bin memory 300 may be an off-chip dynamic random access memory (DRAM), and may include a vertex position buffer (VPB) 302, a vertex flag buffer (VFB) 304, a vertex varying buffer (VVB) 306, a bin buffer 308, a circular overflow (COV) buffer, and miscellaneous buffers (not shown).”)
24. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 4 of Jin in view of Akenine-Moller, and further in view of Øygard to include the disclosure of allocating a region of off-chip storage to a geometry task on creation of the geometry task, receiving a memory allocation request for the geometry task from the shader core, wherein the memory allocation request is received after generation of the position data and determining whether to allocate a region of the vertex buffer to the geometry task, wherein the position data and varyings are written to the vertex buffer and in response to determining not to allocate the region of the vertex buffer, the position data and varyings are written to the allocated region of off-chip storage, of Zhao. The motivation for this modification could have been to provide an option to determine whether to allocate and store position data and varyings in the vertex buffer or off-chip storage. This has the potential advantage of off-loading data that might normally be “on-chip” to “off-chip” storage, helping to prioritize on-chip resources for data and processes that are immediately needed.
25. As per claim 6, Jin in view of Akenine-Moller, further in view of Øygard, and further in view of Zhao discloses: The method according to claim 5, further comprising: (See rejection for claim 5.)
freeing the allocations in response to the task completing or being terminated. (Zhao, [0035], “It should be noted that the COV buffer 310 will circularly reuse its free space. When the COV buffer 310 is full, the COV buffer 310 will stall until any free space becomes available due to a stored vertex attribute shading result of an in-tile vertex data being referenced by the pixel shader 104.”)
26. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 4 of Jin in view of Akenine-Moller, and further in view of Øygard to include the disclosure of freeing the allocations in response to the task completing or being terminated, of Zhao. The motivation for this modification could have been to free resources for tasks that are no longer executing. This would help to make those resources available for other active processes.
27. As per claim 8, Jin in view of Akenine-Moller, further in view of Øygard, and further in view of Zhao discloses: The method according to claim 4, further comprising: (See rejection for claim 4.)
allocating a region of off-chip storage to a geometry task on creation of the geometry task; (Zhao, [0022], “Specifically, concerning each primitive having vertices processed by the preceding vertex position shader 112 and required to be processed by the following pixel shader 104, the binning module 103 checks distribution of the primitive in the screen space to find out bin(s) covered by the primitive, and stores primitive information of the primitive into a table (or a list) in the first storage device 106 (e.g., an off-chip bin memory).” and [0035], “With regard to the COV buffer 310 shown in FIG. 3, it is a fixed-size buffer allocated in the bin memory 300, and is used to buffer varying data (i.e., vertex attribute shading results) of in-tile vertices generated from the vertex attribute shader 114 when an overflow condition of the second storage device 110 is met. When the COV buffer 310 is not full yet, a free space is allocated in the COV buffer 310 for buffering the overflowed varying data. In addition, a vertex pointer in VPB 302 is set to point to this allocated space in COV buffer 310. ... Though the COV buffer 310 is allocated in the off-chip bin memory, the COV buffer 310 is implemented using a fixed-size buffer, which is beneficial for bin memory size control.”)
receiving, at the vertex buffer, a first memory allocation request for the geometry task from the shader core, wherein the first memory allocation request is received after generation of the position data; and (Zhao, [0022], “Specifically, concerning each primitive having vertices processed by the preceding vertex position shader 112 and required to be processed by the following pixel shader 104, the binning module 103 checks distribution of the primitive in the screen space to find out bin(s) covered by the primitive, and stores primitive information of the primitive into a table (or a list) in the first storage device 106 (e.g., an off-chip bin memory).” and [0035], “With regard to the COV buffer 310 shown in FIG. 3, it is a fixed-size buffer allocated in the bin memory 300, and is used to buffer varying data (i.e., vertex attribute shading results) of in-tile vertices generated from the vertex attribute shader 114 when an overflow condition of the second storage device 110 is met. When the COV buffer 310 is not full yet, a free space is allocated in the COV buffer 310 for buffering the overflowed varying data. In addition, a vertex pointer in VPB 302 is set to point to this allocated space in COV buffer 310. ... Though the COV buffer 310 is allocated in the off-chip bin memory, the COV buffer 310 is implemented using a fixed-size buffer, which is beneficial for bin memory size control.” and [0031], “The binning result generated by the binning module 103 and the classification result generated by the vertex classification module 102 are stored into the first storage device 106. In one exemplary design, the first storage device 106 may be implemented using a bin memory 300 shown in FIG. 3. The bin memory 300 may be an off-chip dynamic random access memory (DRAM), and may include a vertex position buffer (VPB) 302, a vertex flag buffer (VFB) 304, a vertex varying buffer (VVB) 306, a bin buffer 308, a circular overflow (COV) buffer, and miscellaneous buffers (not shown).”)
in response to receiving the first memory allocation request, determining, by the vertex buffer, whether to allocate a first region of the vertex buffer to the geometry task; (Zhao, [0035], “With regard to the COV buffer 310 shown in FIG. 3, it is a fixed-size buffer allocated in the bin memory 300, and is used to buffer varying data (i.e., vertex attribute shading results) of in-tile vertices generated from the vertex attribute shader 114 when an overflow condition of the second storage device 110 is met. When the COV buffer 310 is not full yet, a free space is allocated in the COV buffer 310 for buffering the overflowed varying data. … When the COV buffer 310 is full, the COV buffer 310 will stall until any free space becomes available due to a stored vertex attribute shading result of an in-tile vertex data being referenced by the pixel shader 104. In this embodiment, the second storage device 110 may be implemented using an on-chip cache. The vertex attribute shading results of in-tile vertices are not kept in the VVB 306, but may be kept in the second storage device 110 (if the overflow condition is not met) or the COV buffer 310 (if the overflow condition is met). In other words, the priority of writing vertex attribute shading results of in-tile vertices into the on-chip cache is higher than the priority of writing vertex attribute shading results of in-tile vertices into a fixed-size buffer allocated in an off-chip bin memory. Though the COV buffer 310 is allocated in the off-chip bin memory, the COV buffer 310 is implemented using a fixed-size buffer, which is beneficial for bin memory size control.”)
wherein in response to allocating the first region of the vertex buffer, the position data is written to the first region of the vertex buffer and in response to determining not to allocate the first region of the vertex buffer, the position data is written to the allocated region of off-chip storage. (Zhao, [0040], “The vertex attribute shader 114 applies different storage strategies to vertex attribute shading results (i.e., varying data) of the in-tile vertices and vertex attribute shading results (i.e., varying data) of the out-tile vertices. Specifically, the vertex attribute shading results (i.e., varying data) of at least a portion (i.e., part or all) of the in-tile vertices processed by the vertex attribute shader 114 are stored in the second storage device (e.g., on-chip cache) 110 only, while the vertex attribute shading results (i.e., varying data) of all out-tile vertices processed by the vertex attribute shader 114 will be eventually written into the first storage device (e.g., off-chip bin memory) 106.” and [0035], “With regard to the COV buffer 310 shown in FIG. 3, it is a fixed-size buffer allocated in the bin memory 300, and is used to buffer varying data (i.e., vertex attribute shading results) of in-tile vertices generated from the vertex attribute shader 114 when an overflow condition of the second storage device 110 is met. When the COV buffer 310 is not full yet, a free space is allocated in the COV buffer 310 for buffering the overflowed varying data. … When the COV buffer 310 is full, the COV buffer 310 will stall until any free space becomes available due to a stored vertex attribute shading result of an in-tile vertex data being referenced by the pixel shader 104. In this embodiment, the second storage device 110 may be implemented using an on-chip cache. The vertex attribute shading results of in-tile vertices are not kept in the VVB 306, but may be kept in the second storage device 110 (if the overflow condition is not met) or the COV buffer 310 (if the overflow condition is met). In other words, the priority of writing vertex attribute shading results of in-tile vertices into the on-chip cache is higher than the priority of writing vertex attribute shading results of in-tile vertices into a fixed-size buffer allocated in an off-chip bin memory. Though the COV buffer 310 is allocated in the off-chip bin memory, the COV buffer 310 is implemented using a fixed-size buffer, which is beneficial for bin memory size control.” and [0031], “The binning result generated by the binning module 103 and the classification result generated by the vertex classification module 102 are stored into the first storage device 106. In one exemplary design, the first storage device 106 may be implemented using a bin memory 300 shown in FIG. 3. The bin memory 300 may be an off-chip dynamic random access memory (DRAM), and may include a vertex position buffer (VPB) 302, a vertex flag buffer (VFB) 304, a vertex varying buffer (VVB) 306, a bin buffer 308, a circular overflow (COV) buffer, and miscellaneous buffers (not shown).”)
28. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 4 of Jin in view of Akenine-Moller, and further in view of Øygard to include the disclosure of allocating a region of off-chip storage to a geometry task on creation of the geometry task, receiving a first memory allocation request for the geometry task from the shader core, wherein the first memory allocation request is received after generation of the position data, and determining whether to allocate a first region of the vertex buffer to the geometry task, wherein the position data is written to the first region of the vertex buffer and in response to determining not to allocate the first region of the vertex buffer, the position data is written to the allocated region of off-chip storage, of Zhao. The motivation for this modification could have been to provide an option to determine whether to allocate and store position data and varyings in the vertex buffer or off-chip storage. This has the potential advantage of off-loading data that might normally be “on-chip” to “off-chip” storage, helping to prioritize on-chip resources for data and processes that are immediately needed.
29. As per claim 9, Jin in view of Akenine-Moller, further in view of Øygard, and further in view of Zhao discloses: The method according to claim 8, further comprising, after receiving cull results indicating at least one remaining instance in the task that has not been culled: (See rejections for claims 1, 4, and 8.)
receiving, at the vertex buffer, a second memory allocation request for the geometry task from the shader core, wherein the second memory allocation request is received after generation of the varyings; and (Øygard, [0103], “In a second such embodiment, therefore, in the situation where the first, pre-pass operation only processes the vertex position attributes (such that the processing of any other, non-position (varyings) attributes is omitted by the first, pre-pass operation), the first, pre-pass operation may nonetheless still allocate enough space in vertex storage for the entire set of vertex attributes. That is, in this embodiment, the first, pre-pass operation allocates enough space in vertex storage for the entire vertex, including both vertex position and vertex non-position (varyings) attributes, regardless of whether or not the vertex non-position (varyings) attributes are required.”)
in response to receiving the second memory allocation request, determining, by the vertex buffer, whether to allocate a second region of the vertex buffer to the geometry task; (Øygard, [0104]-[0105], “In this embodiment, the first, pre-pass operation may therefore (in the case where the non-position (varyings) attributes are not required for the first, pre-pass operation) only populate the vertex position attributes during the first, pre-pass operation. However, the allocation remains available for the second, main pass operation and the vertex non-position (varyings) attributes can accordingly be populated at that point. This approach thus allows the same allocation to be used for both passes, and the results from the first, pre-pass operation to be easily re-used for the second, main pass. However, this approach requires a larger allocation during the first, pre-pass operation. This can therefore increase the possibility of allocation stalls, especially for fixed-size vertex storage.”)
wherein in response to allocating the second region of the vertex buffer, the varyings are written to the second region of the vertex buffer and in response to determining not to allocate the second region of the vertex buffer, the varyings are written to the allocated region (Øygard, [0104]-[0105], “In this embodiment, the first, pre-pass operation may therefore (in the case where the non-position (varyings) attributes are not required for the first, pre-pass operation) only populate the vertex position attributes during the first, pre-pass operation. However, the allocation remains available for the second, main pass operation and the vertex non-position (varyings) attributes can accordingly be populated at that point. This approach thus allows the same allocation to be used for both passes, and the results from the first, pre-pass operation to be easily re-used for the second, main pass. However, this approach requires a larger allocation during the first, pre-pass operation. This can therefore increase the possibility of allocation stalls, especially for fixed-size vertex storage.”) of off-chip storage. (Zhao, [0040], “The vertex attribute shader 114 applies different storage strategies to vertex attribute shading results (i.e., varying data) of the in-tile vertices and vertex attribute shading results (i.e., varying data) of the out-tile vertices. Specifically, the vertex attribute shading results (i.e., varying data) of at least a portion (i.e., part or all) of the in-tile vertices processed by the vertex attribute shader 114 are stored in the second storage device (e.g., on-chip cache) 110 only, while the vertex attribute shading results (i.e., varying data) of all out-tile vertices processed by the vertex attribute shader 114 will be eventually written into the first storage device (e.g., off-chip bin memory) 106.” and [0035], “With regard to the COV buffer 310 shown in FIG. 3, it is a fixed-size buffer allocated in the bin memory 300, and is used to buffer varying data (i.e., vertex attribute shading results) of in-tile vertices generated from the vertex attribute shader 114 when an overflow condition of the second storage device 110 is met. When the COV buffer 310 is not full yet, a free space is allocated in the COV buffer 310 for buffering the overflowed varying data. … When the COV buffer 310 is full, the COV buffer 310 will stall until any free space becomes available due to a stored vertex attribute shading result of an in-tile vertex data being referenced by the pixel shader 104. In this embodiment, the second storage device 110 may be implemented using an on-chip cache. The vertex attribute shading results of in-tile vertices are not kept in the VVB 306, but may be kept in the second storage device 110 (if the overflow condition is not met) or the COV buffer 310 (if the overflow condition is met). In other words, the priority of writing vertex attribute shading results of in-tile vertices into the on-chip cache is higher than the priority of writing vertex attribute shading results of in-tile vertices into a fixed-size buffer allocated in an off-chip bin memory. Though the COV buffer 310 is allocated in the off-chip bin memory, the COV buffer 310 is implemented using a fixed-size buffer, which is beneficial for bin memory size control.” and [0031], “The binning result generated by the binning module 103 and the classification result generated by the vertex classification module 102 are stored into the first storage device 106. In one exemplary design, the first storage device 106 may be implemented using a bin memory 300 shown in FIG. 3. The bin memory 300 may be an off-chip dynamic random access memory (DRAM), and may include a vertex position buffer (VPB) 302, a vertex flag buffer (VFB) 304, a vertex varying buffer (VVB) 306, a bin buffer 308, a circular overflow (COV) buffer, and miscellaneous buffers (not shown).”)
30. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 8 of Jin in view of Akenine-Moller, and further in view of Øygard to include the disclosure of writing varyings to the allocated region of off-chip storage, of Zhao. The motivation for this modification could have been to provide a resource to offload the positional and varying information on to external storage until it is needed at a later point in time. This helps to prioritize on-chip resources for processes and data that are actively executing.
31. Claim 18 is similar in scope to dependent claims 8 and 17 and independent claim 14 except for a different limitation that Jin in view of Akenine-Moller, further in view of Øygard, and further in view of Zhao discloses: The GPU according to claim 17, further comprising a resource scheduler arranged to [[allocate a region of off-chip storage to a geometry task on creation of the geometry task, and wherein the vertex buffer is further arranged to:]] (Akenine-Moller, [0070], “While waiting for data from memory or one of the shared functions, dependency logic within the execution units 608A-608N causes a waiting thread to sleep until the requested data has been returned. While the waiting thread is sleeping, hardware resources may be devoted to processing other threads. For example, during a delay associated with a vertex shader operation, an execution unit can perform operations for a pixel shader, fragment shader, or another type of shader program, including a different vertex shader.” and [0065], “In some embodiments, graphics processor 500 includes scalable thread execution resources featuring modular cores 580A-580N (sometimes referred to as core slices), each having multiple sub-cores 550A-550N, 560A-560N (sometimes referred to as core sub-slices). ... In some embodiments, each sub-core 550A-550N, 560A-560N shares a set of shared resources 570A-570N. In some embodiments, the shared resources include shared cache memory and pixel operation logic. Other shared resources may also be included in the various embodiments of the graphics processor.”)
32. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the GPU of claim 17 of Jin in view of Øygard, and further in view of Zhao to include the disclosure of utilizing a resource scheduler, of Akenine-Moller. The motivation for this modification could have been to have a formal scheduler that helps to allocate resources among the resources available. The scheduler could help provide limited resources to multiple processes so that all processes can make progress in their execution.
33. Claim 19, which is similar in scope to dependent claim 9 and independent claim 14, is thus rejected under the same rationale as described above. The motivation for this modification is the same as claim 9.
34. Claims 7 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Jin et al. (US-2018/0033184-A1, hereinafter "Jin") in view of Akenine-Moller et al. (US-2018/0082464-A1, hereinafter "Akenine-Moller"), further in view of Øygard et al. (EP-4411651-A1, hereinafter "Øygard"), further in view of Zhao et al. (US-2016/0035128-A1, hereinafter "Zhao"), and further in view of French et al. (US-8228328-B1, hereinafter "French").
35. As per claim 7, Jin in view of Akenine-Moller, further in view of Øygard, and further in view of Zhao discloses: The method according to claim 5, the method further comprising: (See rejection for claim 5.)
[[on creation of the geometry task, sending an identifier for the geometry task to the vertex buffer and adding the identifier to a FIFO in the vertex buffer; and]]
in response to receiving the memory allocation request at the vertex buffer and prior to determining, by the vertex buffer, whether to allocate a region of the vertex buffer to the geometry task: (Zhao, [0035], “With regard to the COV buffer 310 shown in FIG. 3, it is a fixed-size buffer allocated in the bin memory 300, and is used to buffer varying data (i.e., vertex attribute shading results) of in-tile vertices generated from the vertex attribute shader 114 when an overflow condition of the second storage device 110 is met. When the COV buffer 310 is not full yet, a free space is allocated in the COV buffer 310 for buffering the overflowed varying data. … When the COV buffer 310 is full, the COV buffer 310 will stall until any free space becomes available due to a stored vertex attribute shading result of an in-tile vertex data being referenced by the pixel shader 104. In this embodiment, the second storage device 110 may be implemented using an on-chip cache. The vertex attribute shading results of in-tile vertices are not kept in the VVB 306, but may be kept in the second storage device 110 (if the overflow condition is not met) or the COV buffer 310 (if the overflow condition is met). In other words, the priority of writing vertex attribute shading results of in-tile vertices into the on-chip cache is higher than the priority of writing vertex attribute shading results of in-tile vertices into a fixed-size buffer allocated in an off-chip bin memory. Though the COV buffer 310 is allocated in the off-chip bin memory, the COV buffer 310 is implemented using a fixed-size buffer, which is beneficial for bin memory size control.”)
[[setting a bit in a mask corresponding to the identifier for the geometry task, wherein the memory allocation request comprises the identifier for the geometry task;]]
[[determining whether the identifier for the geometry task is in a first position in the FIFO; and]]
[[in response to determining that the identifier for the geometry task is in a first position in the FIFO, popping the task from the FIFO and proceeding to determine whether to allocate a region of the vertex buffer to the geometry task.]]
36. Jin in view of Akenine-Moller, further in view of Øygard, and further in view of Zhao doesn't explicitly disclose but French discloses: on creation of the geometry task, sending an identifier for the geometry task to the vertex buffer and adding the identifier to a FIFO in the vertex buffer; and (French, col. 4, lines 40-53, “The mapping of (x,y) pixel positions in a render target to the multiple partitions may be changed without idling the graphics processing pipeline by linking each pixel tile being processed with a partition identifier. Each pixel tile maps to exactly one partition associated with a unique partition identifier. The partition identifier is determined by a memory management unit and accompanies the pixel tile through the graphics processing pipeline to control routing of the pixel tile to the proper partition. A multi-threaded FIFO is used to decouple the shader processing from the backend processing. The multi-threaded FIFO stores z pass data produced by the ZROP units in separate queues according to the partition identifiers and the z pass data is matched to pixel tile data to produce per-sample coverage data.” and col. 10, 35-41, “PROP unit 220 receives z pass data, including z pass coverage masks for shaded pixel tiles from the particular raster operations unit 160 that performed z testing for shaded pixel tiles received by PROP unit 220. The z pass data is stored in an entry of multi-threaded z pass FIFO 310 based on A ZROP partition identifier is produced by PROP unit 220 and accompanies the z data that is output to z crossbar 230.”)
setting a bit in a mask corresponding to the identifier for the geometry task, wherein the memory allocation request comprises the identifier for the geometry task; (French, col. 11, lines 51-63, “When a z pass coverage mask for the partition is available, in step 420 reconciler 340 reads the z pass coverage mask using the ZROP partition identifier, reading the first entry in multi-threaded z pass FIFO 310 queued for the partition. Notably, the first entry is not necessarily popped since each z pass coverage mask may correspond to more than one data packet. Multi-threaded z pass FIFO 310 allows for an entry for any partition to be read without being popped. In step 430 reconciler 340 computes the post-z pass coverage mask for the data packet by performing a bit-wise AND between the portion of the rasterized coverage mask included in the data packet and the corresponding portion of the z pass coverage mask read in step 420.”)
determining whether the identifier for the geometry task is in a first position in the FIFO; and (French, col. 11, lines 51-63, “When a z pass coverage mask for the partition is available, in step 420 reconciler 340 reads the z pass coverage mask using the ZROP partition identifier, reading the first entry in multi-threaded z pass FIFO 310 queued for the partition. Notably, the first entry is not necessarily popped since each z pass coverage mask may correspond to more than one data packet. Multi-threaded z pass FIFO 310 allows for an entry for any partition to be read without being popped. In step 430 reconciler 340 computes the post-z pass coverage mask for the data packet by performing a bit-wise AND between the portion of the rasterized coverage mask included in the data packet and the corresponding portion of the z pass coverage mask read in step 420.”)
in response to determining that the identifier for the geometry task is in a first position in the FIFO, popping the task from the FIFO and proceeding to determine whether to allocate a region of the vertex buffer to the geometry task. (French, col. 10, lines 21-34, “Even though a new tile mapping may be stored in partition mapping table 320 after a context switch, the sequencing and popping of z pass FIFO 310 may continue since the partition identifiers are pipelined with the z pass data. However, when virtual addressing is used, then virtual to physical memory mapping may have changed during the context switch, so pixel data previously assigned to one partition may not be mapped to that same partition. In that case, all in-flight data sent to ZROP unit 270 must complete processing (drain) and be reconciled with the data stored in a multi-threaded z pass FIFO 310. When the in-flight data is processed, the virtual to physical memory mapping may be changed in partition mapping table 320 and processing is resumed using the new context.”)
37. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 5 of Jin in view of Akenine-Moller, further in view of Øygard, and further in view of Zhao to include the disclosure of when creating the geometry task, sending an identifier for the geometry task to the vertex buffer and adding the identifier to a FIFO in the vertex buffer, setting a bit in a mask corresponding to the identifier for the geometry task, wherein the memory allocation request comprises the identifier for the geometry task, determining whether the identifier for the geometry task is in a first position in the FIFO, popping the task from the FIFO and proceeding to determine whether to allocate a region of the vertex buffer to the geometry task, of French. The motivation for this modification could have been to use a FIFO system to help keep track of various graphics tasks and then determine whether to allocate resources for the task when it reaches the first position in the FIFO. This helps to handle the tasks in the order they are received and properly allocate resources to those tasks.
38. As per claim 13, Jin in view of Akenine-Moller, further in view of Øygard, further in view of Zhao, and further in view of French discloses: The method according to claim 8, further comprising: (See rejection for claim 8.)
on creation of the geometry task, sending an identifier for the geometry task to the vertex buffer and adding the identifier to both a first FIFO and a second FIFO in the vertex buffer; (French, col. 11, lines 16-20, “Multi-threaded z pass FIFO 310 allows for the returned z pass data to be stored in separate queues within a single memory structure. The separate queues appear as separate conventional FIFOs, while permitting a dynamic allocation of the FIFO entries between the different partitions.” and col. 4, lines 40-53, “The mapping of (x,y) pixel positions in a render target to the multiple partitions may be changed without idling the graphics processing pipeline by linking each pixel tile being processed with a partition identifier. Each pixel tile maps to exactly one partition associated with a unique partition identifier. The partition identifier is determined by a memory management unit and accompanies the pixel tile through the graphics processing pipeline to control routing of the pixel tile to the proper partition. A multi-threaded FIFO is used to decouple the shader processing from the backend processing. The multi-threaded FIFO stores z pass data produced by the ZROP units in separate queues according to the partition identifiers and the z pass data is matched to pixel tile data to produce per-sample coverage data.” and col. 10, 35-41, “PROP unit 220 receives z pass data, including z pass coverage masks for shaded pixel tiles from the particular raster operations unit 160 that performed z testing for shaded pixel tiles received by PROP unit 220. The z pass data is stored in an entry of multi-threaded z pass FIFO 310 based on A ZROP partition identifier is produced by PROP unit 220 and accompanies the z data that is output to z crossbar 230.”)
in response to receiving the first memory allocation request at the vertex buffer and prior to determining, by the vertex buffer, whether to allocate a first region of the vertex buffer to the geometry task: (Zhao, [0035], “With regard to the COV buffer 310 shown in FIG. 3, it is a fixed-size buffer allocated in the bin memory 300, and is used to buffer varying data (i.e., vertex attribute shading results) of in-tile vertices generated from the vertex attribute shader 114 when an overflow condition of the second storage device 110 is met. When the COV buffer 310 is not full yet, a free space is allocated in the COV buffer 310 for buffering the overflowed varying data. … When the COV buffer 310 is full, the COV buffer 310 will stall until any free space becomes available due to a stored vertex attribute shading result of an in-tile vertex data being referenced by the pixel shader 104. In this embodiment, the second storage device 110 may be implemented using an on-chip cache. The vertex attribute shading results of in-tile vertices are not kept in the VVB 306, but may be kept in the second storage device 110 (if the overflow condition is not met) or the COV buffer 310 (if the overflow condition is met). In other words, the priority of writing vertex attribute shading results of in-tile vertices into the on-chip cache is higher than the priority of writing vertex attribute shading results of in-tile vertices into a fixed-size buffer allocated in an off-chip bin memory. Though the COV buffer 310 is allocated in the off-chip bin memory, the COV buffer 310 is implemented using a fixed-size buffer, which is beneficial for bin memory size control.”)
setting a bit in a first mask corresponding to the identifier for the geometry task, wherein the first memory allocation request comprises the identifier for the geometry task, (French, col. 11, lines 51-63, “When a z pass coverage mask for the partition is available, in step 420 reconciler 340 reads the z pass coverage mask using the ZROP partition identifier, reading the first entry in multi-threaded z pass FIFO 310 queued for the partition. Notably, the first entry is not necessarily popped since each z pass coverage mask may correspond to more than one data packet. Multi-threaded z pass FIFO 310 allows for an entry for any partition to be read without being popped. In step 430 reconciler 340 computes the post-z pass coverage mask for the data packet by performing a bit-wise AND between the portion of the rasterized coverage mask included in the data packet and the corresponding portion of the z pass coverage mask read in step 420.”) determining whether the identifier for the geometry task is in a first position in the first FIFO, (French, col. 11, lines 51-63, “When a z pass coverage mask for the partition is available, in step 420 reconciler 340 reads the z pass coverage mask using the ZROP partition identifier, reading the first entry in multi-threaded z pass FIFO 310 queued for the partition. Notably, the first entry is not necessarily popped since each z pass coverage mask may correspond to more than one data packet. Multi-threaded z pass FIFO 310 allows for an entry for any partition to be read without being popped. In step 430 reconciler 340 computes the post-z pass coverage mask for the data packet by performing a bit-wise AND between the portion of the rasterized coverage mask included in the data packet and the corresponding portion of the z pass coverage mask read in step 420.”) and in response to determining that the identifier for the geometry task is in a first position in the first FIFO, popping the task from the first FIFO and proceeding to determine whether to allocate a first region of the vertex buffer to the geometry task; and, (French, col. 10, lines 21-34, “Even though a new tile mapping may be stored in partition mapping table 320 after a context switch, the sequencing and popping of z pass FIFO 310 may continue since the partition identifiers are pipelined with the z pass data. However, when virtual addressing is used, then virtual to physical memory mapping may have changed during the context switch, so pixel data previously assigned to one partition may not be mapped to that same partition. In that case, all in-flight data sent to ZROP unit 270 must complete processing (drain) and be reconciled with the data stored in a multi-threaded z pass FIFO 310. When the in-flight data is processed, the virtual to physical memory mapping may be changed in partition mapping table 320 and processing is resumed using the new context.”)
in response to receiving the second memory allocation request at the vertex buffer and prior to determining, by the vertex buffer, whether to allocate a second region of the vertex buffer to the geometry task: (Øygard, [0098], “The second, main pass operation should thus (and preferably does) make a new allocation for the entire set of attributes for a vertex (i.e. including both the position and the non-position (varyings) attributes for the vertex).” and Zhao, [0035], “With regard to the COV buffer 310 shown in FIG. 3, it is a fixed-size buffer allocated in the bin memory 300, and is used to buffer varying data (i.e., vertex attribute shading results) of in-tile vertices generated from the vertex attribute shader 114 when an overflow condition of the second storage device 110 is met. When the COV buffer 310 is not full yet, a free space is allocated in the COV buffer 310 for buffering the overflowed varying data. … When the COV buffer 310 is full, the COV buffer 310 will stall until any free space becomes available due to a stored vertex attribute shading result of an in-tile vertex data being referenced by the pixel shader 104. In this embodiment, the second storage device 110 may be implemented using an on-chip cache. The vertex attribute shading results of in-tile vertices are not kept in the VVB 306, but may be kept in the second storage device 110 (if the overflow condition is not met) or the COV buffer 310 (if the overflow condition is met). In other words, the priority of writing vertex attribute shading results of in-tile vertices into the on-chip cache is higher than the priority of writing vertex attribute shading results of in-tile vertices into a fixed-size buffer allocated in an off-chip bin memory. Though the COV buffer 310 is allocated in the off-chip bin memory, the COV buffer 310 is implemented using a fixed-size buffer, which is beneficial for bin memory size control.”)
setting a bit in a second mask corresponding to the identifier for the geometry task, (French, col. 2, lines 48-54, “Per-sample z values are computed and z tested to produce z pass coverage masks based on the current z buffer that are independent of any color buffers. When multiple render targets are used, z pass coverage masks are copied for each one of the additional color buffers. The copying may be used with either early or late z testing to improve z testing efficiency and graphics rendering performance.” and col. 11, lines 51-63, “When a z pass coverage mask for the partition is available, in step 420 reconciler 340 reads the z pass coverage mask using the ZROP partition identifier, reading the first entry in multi-threaded z pass FIFO 310 queued for the partition. Notably, the first entry is not necessarily popped since each z pass coverage mask may correspond to more than one data packet. Multi-threaded z pass FIFO 310 allows for an entry for any partition to be read without being popped. In step 430 reconciler 340 computes the post-z pass coverage mask for the data packet by performing a bit-wise AND between the portion of the rasterized coverage mask included in the data packet and the corresponding portion of the z pass coverage mask read in step 420.”) wherein the second memory allocation request comprises the identifier for the geometry task, (Øygard, [0098], “The second, main pass operation should thus (and preferably does) make a new allocation for the entire set of attributes for a vertex (i.e. including both the position and the non-position (varyings) attributes for the vertex).” and French, col. 4, lines 40-53, “The mapping of (x,y) pixel positions in a render target to the multiple partitions may be changed without idling the graphics processing pipeline by linking each pixel tile being processed with a partition identifier. Each pixel tile maps to exactly one partition associated with a unique partition identifier. The partition identifier is determined by a memory management unit and accompanies the pixel tile through the graphics processing pipeline to control routing of the pixel tile to the proper partition. A multi-threaded FIFO is used to decouple the shader processing from the backend processing. The multi-threaded FIFO stores z pass data produced by the ZROP units in separate queues according to the partition identifiers and the z pass data is matched to pixel tile data to produce per-sample coverage data.” and col. 10, 35-41, “PROP unit 220 receives z pass data, including z pass coverage masks for shaded pixel tiles from the particular raster operations unit 160 that performed z testing for shaded pixel tiles received by PROP unit 220. The z pass data is stored in an entry of multi-threaded z pass FIFO 310 based on A ZROP partition identifier is produced by PROP unit 220 and accompanies the z data that is output to z crossbar 230.”) determining whether the identifier for the geometry task is in a first position in the second FIFO, (French, col. 11, lines 16-20, “Multi-threaded z pass FIFO 310 allows for the returned z pass data to be stored in separate queues within a single memory structure. The separate queues appear as separate conventional FIFOs, while permitting a dynamic allocation of the FIFO entries between the different partitions.” and col. 11, lines 51-63, “When a z pass coverage mask for the partition is available, in step 420 reconciler 340 reads the z pass coverage mask using the ZROP partition identifier, reading the first entry in multi-threaded z pass FIFO 310 queued for the partition. Notably, the first entry is not necessarily popped since each z pass coverage mask may correspond to more than one data packet. Multi-threaded z pass FIFO 310 allows for an entry for any partition to be read without being popped. In step 430 reconciler 340 computes the post-z pass coverage mask for the data packet by performing a bit-wise AND between the portion of the rasterized coverage mask included in the data packet and the corresponding portion of the z pass coverage mask read in step 420.”) and in response to determining that the identifier for the geometry task is in a first position in the second FIFO, determining whether the bit in the second mask corresponding to the identifier for the geometry task (French, col. 10, lines 21-34, “Even though a new tile mapping may be stored in partition mapping table 320 after a context switch, the sequencing and popping of z pass FIFO 310 may continue since the partition identifiers are pipelined with the z pass data. However, when virtual addressing is used, then virtual to physical memory mapping may have changed during the context switch, so pixel data previously assigned to one partition may not be mapped to that same partition. In that case, all in-flight data sent to ZROP unit 270 must complete processing (drain) and be reconciled with the data stored in a multi-threaded z pass FIFO 310. When the in-flight data is processed, the virtual to physical memory mapping may be changed in partition mapping table 320 and processing is resumed using the new context.”) is flagged to indicate termination; (Øygard, [0174], “Suitable flags may also be used to determine whether the graphics processor is currently in the pre-pass or main pass state. Thus, when a primitive is being processed, a determination may be made as to the current rendering state of the graphics processor which then controls the processing that is performed.” and [0262], “The primitive classification process shown in Figure 12 may be performed during the first, pre-pass operation by the primitive classification unit 82 with the result of the primitive classification then being used accordingly by the pre-pass decision unit 83 to determine how the processing should continue (i.e. whether the pre-pass operations should continue or whether the pre-pass should be terminated, and the primitive instead subsequently processed by the fallback operation).”)
in response to determining that the bit in the second mask is flagged to indicate termination, (Øygard, [0174], “Suitable flags may also be used to determine whether the graphics processor is currently in the pre-pass or main pass state. Thus, when a primitive is being processed, a determination may be made as to the current rendering state of the graphics processor which then controls the processing that is performed.” and [0262], “The primitive classification process shown in Figure 12 may be performed during the first, pre-pass operation by the primitive classification unit 82 with the result of the primitive classification then being used accordingly by the pre-pass decision unit 83 to determine how the processing should continue (i.e. whether the pre-pass operations should continue or whether the pre-pass should be terminated, and the primitive instead subsequently processed by the fallback operation).”) popping the task from the second FIFO without determining whether to allocate a second region of the vertex buffer to the geometry task; and (French, col. 11, line 64-col. 12, line 1, “In step 435, reconciler 340 determines if the eozp flag in the data packet is asserted, and, if not, reconciler 340 proceeds directly to step 445. Otherwise, in step 440 reconciler 340 pops the z pass coverage mask read in step 420 from multi-threaded z pass FIFO 310.”)
in response to determining that the bit in the second mask is not flagged to indicate termination, popping the task from the second FIFO and proceeding to determine whether to allocate a second region of the vertex buffer to the geometry task. (French, col. 11, lines 16-20, “Multi-threaded z pass FIFO 310 allows for the returned z pass data to be stored in separate queues within a single memory structure. The separate queues appear as separate conventional FIFOs, while permitting a dynamic allocation of the FIFO entries between the different partitions.” and col. 10, lines 21-34, “Even though a new tile mapping may be stored in partition mapping table 320 after a context switch, the sequencing and popping of z pass FIFO 310 may continue since the partition identifiers are pipelined with the z pass data. However, when virtual addressing is used, then virtual to physical memory mapping may have changed during the context switch, so pixel data previously assigned to one partition may not be mapped to that same partition. In that case, all in-flight data sent to ZROP unit 270 must complete processing (drain) and be reconciled with the data stored in a multi-threaded z pass FIFO 310. When the in-flight data is processed, the virtual to physical memory mapping may be changed in partition mapping table 320 and processing is resumed using the new context.”)
39. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 8 of Jin in view of Akenine-Moller, further in view of Øygard, and further in view of Zhao to include the disclosure of on creation of the geometry task, sending an identifier for the geometry task to the vertex buffer and adding the identifier to both a first FIFO and a second FIFO in the vertex buffer, setting a bit in a first and second mask corresponding to the identifier for the geometry task, wherein the first and second memory allocation request comprises the identifier for the geometry task, determining whether the identifier for the geometry task is in a first position in the first FIFO, and in response to determining that the identifier for the geometry task is in a first position in the first FIFO, popping the task from the first FIFO and proceeding to determine whether to allocate a first region of the vertex buffer to the geometry task, and determining whether the bit in the second mask corresponding to the identifier for the geometry task is flagged to indicate termination, popping the task from the second FIFO without determining whether to allocate a second region of the vertex buffer to the geometry task, and popping the task from the second FIFO and proceeding to determine whether to allocate a second region of the vertex buffer to the geometry task, of French. The motivation for this modification could have been to use a FIFO system to help keep track of various graphics tasks and then determine whether to allocate resources for the task when it reaches the first position in the FIFO. This helps to handle the tasks in the order they are received and properly allocate resources to those tasks. In addition, the masks can help determine when certain tasks are complete so that those resources can be freed.
40. Claims 10-12 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jin et al. (US-2018/0033184-A1, hereinafter "Jin") in view of Akenine-Moller et al. (US-2018/0082464-A1, hereinafter "Akenine-Moller"), further in view of Øygard et al. (EP-4411651-A1, hereinafter "Øygard"), further in view of Zhao et al. (US-2016/0035128-A1, hereinafter "Zhao"), and further in view of Hazel (US-2017/0365090-A1, hereinafter "Hazel").
41. As per claim 10, Jin in view of Akenine-Moller, further in view of Øygard, and further in view of Zhao discloses: The method according to claim 9, further comprising: (See rejection for claim 9.)
in response to [[receiving a notification]] that the first part of the geometry task is complete, freeing the first allocation; and (Zhao, [0035], “It should be noted that the COV buffer 310 will circularly reuse its free space. When the COV buffer 310 is full, the COV buffer 310 will stall until any free space becomes available due to a stored vertex attribute shading result of an in-tile vertex data being referenced by the pixel shader 104.”)
in response to the task completing, freeing the off-chip allocation and the second allocation. (Zhao, [0035], “It should be noted that the COV buffer 310 will circularly reuse its free space. When the COV buffer 310 is full, the COV buffer 310 will stall until any free space becomes available due to a stored vertex attribute shading result of an in-tile vertex data being referenced by the pixel shader 104. … Though the COV buffer 310 is allocated in the off-chip bin memory, the COV buffer 310 is implemented using a fixed-size buffer, which is beneficial for bin memory size control.”)
42. Jin in view of Akenine-Moller, further in view of Øygard, and further in view of Zhao doesn't explicitly disclose but Hazel discloses: [[in response to]] receiving a notification [[that the first part of the geometry task is complete, freeing the first allocation; and]] (Hazel, [0493], “In an embodiment, some culling 165 is performed until a local buffer of occluding geometry is filed, and then output sample processing 166 is performed for that occluding geometry so as to free up more space in the buffer. This is then repeated to “refill” the buffer with more occluding geometry, which is then used for further output sample processing to free up space in the buffer, and so on. This can then allow a smaller, local “occluding geometry” buffer that may be more limited in size to be used for storing the occluding geometry that is to be tested when performing the per output sample processing 166.”)
43. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 9 of Jin in view of Akenine-Moller, further in view of Øygard, and further in view of Zhao to include the disclosure of receiving a notification regarding a geometry task, of Hazel. The motivation for this modification could have been to provide information about when various tasks are complete so that those resources can be freed. By actively monitoring the status of running tasks, any completed task can then relinquish those resources for other processes to use.
44. As per claim 11, Jin in view of Akenine-Moller, further in view of Øygard, further in view of Zhao, and further in view of Hazel discloses: The method according to claim 9, further comprising: (See rejection for claim 9.)
in response to receiving cull results indicating at least one remaining instance in the task that has not been culled, freeing the first allocation; and (Hazel, [0493], “In an embodiment, some culling 165 is performed until a local buffer of occluding geometry is filed, and then output sample processing 166 is performed for that occluding geometry so as to free up more space in the buffer. This is then repeated to “refill” the buffer with more occluding geometry, which is then used for further output sample processing to free up space in the buffer, and so on. This can then allow a smaller, local “occluding geometry” buffer that may be more limited in size to be used for storing the occluding geometry that is to be tested when performing the per output sample processing 166.”)
in response to the task completing, freeing the off-chip allocation and the second allocation. (Zhao, [0035], “It should be noted that the COV buffer 310 will circularly reuse its free space. When the COV buffer 310 is full, the COV buffer 310 will stall until any free space becomes available due to a stored vertex attribute shading result of an in-tile vertex data being referenced by the pixel shader 104. … Though the COV buffer 310 is allocated in the off-chip bin memory, the COV buffer 310 is implemented using a fixed-size buffer, which is beneficial for bin memory size control.”)
45. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 9 of Jin in view of Akenine-Moller, further in view of Øygard, and further in view of Zhao to include the disclosure of freeing the first allocation in response to receiving cull results indicating at least one remaining instance in the task that has not been culled, of Hazel. The motivation for this modification could have been to free resources so that other processes can make use of those resources. This helps to optimize overall execution.
46. As per claim 12, Jin in view of Akenine-Moller, further in view of Øygard, further in view of Zhao, and further in view of Hazel discloses: The method according to claim 8, further comprising: (See rejection for claim 8.)
in response to receiving cull results indicating all instances in the task have been culled, freeing the allocations. (Hazel, [0493], “In an embodiment, some culling 165 is performed until a local buffer of occluding geometry is filed, and then output sample processing 166 is performed for that occluding geometry so as to free up more space in the buffer. This is then repeated to “refill” the buffer with more occluding geometry, which is then used for further output sample processing to free up space in the buffer, and so on. This can then allow a smaller, local “occluding geometry” buffer that may be more limited in size to be used for storing the occluding geometry that is to be tested when performing the per output sample processing 166.”)
47. Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to modify the method of claim 8 of Jin in view of Akenine-Moller, further in view of Øygard, and further in view of Zhao to include the disclosure of receiving cull results indicating all instances in the task have been culled, freeing the allocations, of Hazel. The motivation for this modification could have been to free resources so that other processes can make use of those resources. This helps to optimize overall execution.
48. Claim 20, which is similar in scope to dependent claim 10 and independent claim 14, is thus rejected under the same rationale as described above. The motivation for this modification is the same as claim 10.
Conclusion
49. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW CLOTHIER whose telephone number is (571)272-4667. The examiner can normally be reached Mon-Fri 8:00am-4:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kent Chang can be reached at (571)272-7667. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MATTHEW CLOTHIER/Examiner, Art Unit 2614
/KENT W CHANG/Supervisory Patent Examiner, Art Unit 2614
Prosecution Insights