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 .
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 11, 20; 2, 3, 9, 10, 12, 13 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brkic U.S. Pub. No. 2022/0237730 in view of Livesley U.S. Pub. No. 2023/0334614.
Re: claims 1, 11 and 20, (which are rejected under the same rationale), Brkic teaches
1. A graphics processor that is configured to execute a tile-based graphics processing pipeline in which a render output is generated by performing an initial, geometry processing pass and a subsequent, rendering pass, (“The graphics processor 3 shown in FIG. 2 is a tile-based graphics processor that executes a tile-based graphics processing pipeline, and will thus produce rendering tiles of a render output data array, such as an output frame to be generated.”; Brkic, [0139])
Fig. 2 illustrates a tile based graphics processor that includes a tile based graphics processing pipeline that produces rendering of tiles of a render output data array.
(“As shown in FIG. 2, the tile-based graphics processor 3 includes a geometry processor 21, and a renderer 22... The geometry processor 21 comprises, inter alia, a programmable vertex shader 27, and a primitive list building unit 28. The programmable vertex shader 27 takes as it input the raw geometry data 24 stored in the memory 23, and processes that data to provide transformed geometry data 25... comprising the geometry data in a form that is ready for 2D placement in the render output (e.g. frame to be displayed).”; Brkic, 0142], [0144], Fig. 2)
The tile-based graphics processor includes a geometry processor (for the geometry pass) and a renderer (for the rendering pass). The geometry processor processes raw input geometry data and provides the transformed geometry data (geometry pass) to the renderer for rendering (rendering pass).
wherein the initial, geometry processing pass of the graphics processing pipeline being executed by the graphics processor comprises: a sequence of one or more geometry processing stages to perform geometry processing; (“The geometry processor 21 comprises, inter alia, a programmable vertex shader 27, and a primitive list building unit 28. The programmable vertex shader 27 takes as it input the raw geometry data 24 stored in the memory 23, and processes that data to provide transformed geometry data 25... comprising the geometry data in a form that is ready for 2D placement in the render output (e.g. frame to be displayed).”; Brkic, [0145])
The geometry processor includes a vertex shader and a primitive list building unit (sequence of one or mor geometry processing stages to perform geometry processing).
and a binning stage to generate data structures for identifying geometry to be processed when rendering respective tiles of a render output being generated, and wherein the subsequent, rendering pass of the graphics processing pipeline being executed by the graphics processor comprises a rendering stage that renders respective tiles, (“The primitive list building unit (“tiler”) 28 performs the process of “tiling” to allocate primitives to the primitive lists which are then used by the renderer 22 to identify the primitives that should be rendered for each rendering tile that is to be rendered to generate the render output (frame to be rendered for display).”; Brkic, [0145], Fig. 2)
The primitive list building unit (binning stage) performs tiling to allocate primitives to primitive lists (data structure) for each tile (identifying geometry to be processed when rendering respective tiles of a render output being generated). These primitive lists are then used to render each tile (rendering pass... comprises a rendering stage that renders respective tiles) for the render output
wherein the graphics processor has access to a geometry buffer for storing geometry items that are produced by the sequence of one or more geometry processing stages and then consumed during the initial, geometry processing pass, (“The geometry processor 21 comprises, inter alia, a programmable vertex shader 27, and a primitive list building unit 28. The programmable vertex shader 27 takes as it input the raw geometry data 24 stored in the memory 23, and processes that data to provide transformed geometry data 25 (which it then stores in the memory 23) comprising the geometry data in a form that is ready for 2D placement in the render output (e.g. frame to be displayed).”; Brkic, [0144])
The geometry processor includes a vertex shader that processes raw geometry data to produce transformed geometry data, which is stored in memory (geometry buffer).
(“... the primitive list building unit 28 takes as its input the transformed and processed vertex (geometry) data 25 from the programmable vertex shader 27 (i.e. the positions of the primitives in the frame), builds primitive lists using that data, and stores those lists as the primitive lists 26 in the memory 23.”; Brkic,[0145] )
The transformed geometry data is then input (consumed during the initial geometry processing pass) to the primitive list building unit, which builds primitive lists for each tile. The primitive lists are stored in memory (geometry buffer) and consumed for rendering.
Brkic is silent regarding the graphics processor further comprising access logic for controlling access to the geometry buffer, wherein the access logic is operable and configured to control a maximum amount of storage space within the geometry buffer that is available to be allocated for storing new geometry items produced by the sequence of one or more geometry processing stages, however, Livesley teaches
and the graphics processor further comprising access logic for controlling access to the geometry buffer, wherein the access logic is operable and configured to control a maximum amount of storage space within the geometry buffer that is available to be allocated for storing new geometry items produced by the sequence of one or more geometry processing stages. (“... memory is allocated to geometry processing work by an allocation manager. This may also be referred to as a “parameter management” (PM) master unit—so called because it allocates the memory for the parameter buffer. The PM master has a certain free pool of memory that it can allocate to geometry work being performed by different cores. The cores use the allocated memory for writing of tile control lists and primitive blocks. The maximum size of the free pool will depend on the specification of the particular graphics processing system in question, but it is inevitably finite... In order to adapt to these variable storage requirements, it may be advantageous to dynamically allocate the majority of the memory used to store the results of geometry processing.”; Livesley, [0194])
The allocation manager OR PM controls the memory (geometry buffer) and controls access to the memory (geometry buffer) by allocating memory (control the maximum amount of storage space within the geometry buffer that is available to be allocated for storing new geometry items produced by the sequence of one or more geometry stages) to cores (which include geometry stages) for geometry processing work. The allocation manager has a certain free pool of memory, whose maximum size (maximum amount of storage space) depends on the graphics processing system specification. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify method of Brkic by adding the feature of the graphics processor further comprising access logic for controlling access to the geometry buffer, wherein the access logic is operable and configured to control a maximum amount of storage space within the geometry buffer that is available to be allocated for storing new geometry items produced by the sequence of one or more geometry processing stages, in order to use thee available pool of memory as efficiently as possible to avoid situations in which the lack of memory becomes the limiting factor for the continuation of the geometry processing, as taught by Livesley ([0204]).
Claim 20 is a medium analogous to the graphics processor of claim 1, is similar in scope and is rejected under the same rationale. Claim 20 has an additional limitation. Re: claim 20, Brkic teaches
20. A non-transitory computer readable medium storing instructions that when executed by one or more processor will cause the one or more processor to perform a method of operating a graphics processor, (“The technology described herein also extends to a computer software carrier comprising such software which when used to operate a graphics processor, renderer or other system comprising a data processor causes in conjunction with said data processor said processor, renderer or system to carry out the steps of the methods of the technology described herein. Such a computer software carrier could be a physical storage medium such as a ROM chip, CD ROM, RAM, flash memory, or disk, or could be a signal such as an electronic signal over wires, an optical signal or a radio signal such as to a satellite or the like... The technology described herein may accordingly suitably be embodied as a computer program product for use with a computer system. Such an implementation may comprise a series of computer readable instructions fixed on a tangible, non-transitory medium, such as a computer readable medium, for example, diskette, CD ROM, ROM, RAM, flash memory, or hard disk.”; Brkic, [0130], [0132])
A non-transitory computer readable medium stores a computer readable instructions or computer software, that is executed by a processor.
Re: claims 2 and 12, (which are rejected under the same rationale), Brkic and Livesley teach
2. The graphics processor of claim 1, wherein the geometry buffer is configured as a set of one or more memory pools that can be allocated to the sequence of one or more geometry processing stages, and wherein the access logic is operable and configured to control the maximum amount of storage space within the geometry buffer that is available to be allocated for storing new geometry items produced by the sequence of one or more geometry processing stages by: controlling how much of a memory pool within the geometry buffer that has been allocated to the sequence of one or more geometry processing stages is available to be allocated for storing new geometry items. (“... memory is allocated to geometry processing work by an allocation manager. This may also be referred to as a “parameter management” (PM) master unit—so called because it allocates the memory for the parameter buffer. The PM master has a certain free pool of memory that it can allocate to geometry work being performed by different cores.... The maximum size of the free pool will depend on the specification of the particular graphics processing system in question, but it is inevitably finite... In order to adapt to these variable storage requirements, it may be advantageous to dynamically allocate the majority of the memory used to store the results of geometry processing.”; Livesley, [0194])
The allocation manager OR PM, which includes a certain free pool of memory (set of one or more memory pools), that can be allocated to geometry processing (that can be allocated to the sequence of one or more geometry processing stages). The maximum size of the free memory pool depends on the specification of the graphics processing system. And, the majority of the memory (maximum amount of storage space) is dynamically allocated to geometry processing (controls a maximum amount of storage space... by controlling how much of a memory pool within the geometry buffer that has been allocated to the sequence of one or more geometry processing stages is available to be allocated for storing new geometry items).
(“The memory for storing the tile control lists and primitive blocks is allocated dynamically from one or more free stacks by a parameter manager (PM).”; Livesley, [0204])
The memory (geometry buffer) for storing tile control lists and primitive blocks is dynamically allocated (controlling how much of a memory pool... is available to be allocated for storing new geometry items) from one or more free stacks. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Brkic by adding the feature of wherein the geometry buffer is configured as a set of one or more memory pools that can be allocated to the sequence of one or more geometry processing stages, and wherein the access logic is operable and configured to control the maximum amount of storage space within the geometry buffer that is available to be allocated for storing new geometry items produced by the sequence of one or more geometry processing stages by: controlling how much of a memory pool within the geometry buffer that has been allocated to the sequence of one or more geometry processing stages is available to be allocated for storing new geometry items, in order to use thee available pool of memory as efficiently as possible to avoid situations in which the lack of memory becomes the limiting factor for the continuation of the geometry processing, as taught by Livesley ([0204]).
Re: claims 3 and 13, (which are rejected under the same rationale), Brkic and Livesley teach
3. The graphics processor of claim 2, wherein each memory pool has a certain allotted size within the geometry buffer corresponding to a full address range for the memory pool, (“... memory is allocated to geometry processing work by an allocation manager. This may also be referred to as a “parameter management” (PM) master unit—so called because it allocates the memory for the parameter buffer. The PM master has a certain free pool of memory that it can allocate to geometry work being performed by different cores.... The maximum size of the free pool will depend on the specification of the particular graphics processing system in question, but it is inevitably finite...”; Livesley, [0194])
The allocation manager OR PM includes a certain free pool of memory (set of one or more memory pools) that can be allocated to geometry processing. A free pool (memory pool) has maximum size that is finite (has a certain allotted size within the geometry buffer corresponding to a full address range for the memory pool).
and wherein controlling how much of the memory pool is accessible for storing new geometry items comprises selectively restricting the address range that is available to be allocated for storing new geometry items produced by the sequence of one or more geometry processing stages, to thereby control an effective size of the memory pool. (“The allocation manager may be configured to segment the virtualised memory space such that the first cores are allocated respective non-overlapping virtual address ranges in the space, the virtual address ranges being associated with different entries in a top level of the hierarchical index. ”; Livesley, [0060])
The allocation manager segments the virtualized memory such that the cores are allocated non-overlapping virtual address ranges (selectively restricting the address range that is available to be allocated for storing new geometry items produced by the sequence of one or more geometry processing stages, to thereby control an effective size of the memory pool) in the memory space. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Brkic by adding the feature of - each memory pool has a certain allotted size within the geometry buffer corresponding to a full address range for the memory pool, and wherein controlling how much of the memory pool is accessible for storing new geometry items comprises selectively restricting the address range that is available to be allocated for storing new geometry items produced by the sequence of one or more geometry processing stages, to thereby control an effective size of the memory pool, in order to use thee available pool of memory as efficiently as possible to avoid situations in which the lack of memory becomes the limiting factor for the continuation of the geometry processing, as taught by Livesley ([0204]).
Re: claims 9 and 19, (which are rejected under the same rationale), Brkic and Livesley teach
9. The graphics processor of claim 1, wherein the graphics processor comprises a cache that is operable to transfer geometry items produced by the sequence of one or more geometry processing stages between the graphics processor and the geometry buffer, (“... the primitive list building unit 28 takes as its input the transformed and processed vertex (geometry) data 25 from the programmable vertex shader 27... builds primitive lists using that data, and stores those lists as the primitive lists 26 in the memory 23.”; Brkic, [0145], Fig. 2)
Fig. 2 illustrates that the primitive list building unit stores the primitive lists to the memory (geometry buffer).
(“The primitive selection unit 29 of the renderer 22 determines which primitive is to be rendered next. It does this by considering the primitive lists 26 stored in the memory 23, and selecting from one of those lists the next primitive to be rendered. The primitive selection unit 29 can also place one or more primitive lists in the primitive list cache 30 as appropriate.”; Brkic, [0147])
Then, the primitive selection unit determines which primitive lists, which are stored in the memory, to render next. The primitive selection unit then places the primitive lists in the primitive list cache (which is also considered to be a geometry buffer). The primitive list cache
and wherein the geometry buffer is configured and sized to fit within the cache. (“The primitive selection unit 29 can also place one or more primitive lists in the primitive list cache 30 as appropriate.”; Brkic, [0147])
The primitive list cache is considered to be a geometry buffer (geometry buffer is configured and sized to fit within the cache).
Re: claim 10, Brkic and Livesley teach
10. The graphics processor of claim 1, comprising a set of plural processing cores, wherein the binning stage is distributed between the set of plural processing cores. (“The tile control list for a given tile written by a given core contains PIM markers which are used to stitch together the PIM sections from multiple tile control lists for the same tile (one from each core) into a combined control stream in PIM order. ”; Livesley, [0191], Fig. 2A)
Fig. 2A illustrates core 0 and core 1 (set of plural processing cores). The tile control lists (binning stage) written by a given core includes PIM markers which are used to stitch together PIM (primitive groups) sections from multiple tile control lists for the same tile (one from each core).
(“The tile control lists produced by the cores during geometry processing form the input for the fragment processing stage.”; Livesley, [0193])
The cores produce tile control lists during geometry processing (binning stage).
(“A mask in the tile control list may be used to indicate which of the primitives in the primitive block belong to the “current” tile. Each tile control list therefore identifies primitives associated with a tile within the primitive block structures in the parameter buffer.”; Livesley, [0197])
The tile control lists includes a mask that indicates which primitives in the primitive block belong to the current tile (binning).
(“FIG. 1 is a block diagram illustrating a multicore graphics rendering system 100 according to an example. The system 100 comprises two cores in this example—a first core 101, and a second core 111.”; Livesley, [0242], Fig. 1)
Fig. 1 illustrates a multicore graphics rendering system (graphics processor) which includes core 0 and core 1 (a set of plural processing cores).
(“The first core 101 (Core 0) provides a first tile control list 201 for Tile (0, 0), containing the primitives of PIM0, PIM2, PIM5 and PIM6 that fall within the tile; the second core 111 (Core 1) provides a tile control list 211 containing the primitives of PIM1, PIM3 and PIM4 that fall within the tile.”; Livesley, [0249], Figs. 2A-2B)
Figs. 2A-2B illustrate that the tile control lists (binning stage) 201, 211 are distributed between core 1 and core 1 (the set of plural processing cores). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Brkic by adding the feature of the graphics processor comprising a set of plural processing cores, wherein the binning stage is distributed between the set of plural processing cores, in order to use thee available pool of memory as efficiently as possible to avoid situations in which the lack of memory becomes the limiting factor for the continuation of the geometry processing, as taught by Livesley ([0204]).
Claim(s) 4, 5, 6, 14, 15 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brkic in view of Livesley as applied to claims 3 and 13 above, and further in view of Livesley U.S. Pub. No. 2023/0333895 (hereinafter Livesley’895).
Re: claims 4 and 14, (which are rejected under the same rationale), Brkic and Livesley are silent regarding the access logic is operable to select between a first effective memory pool size in which the full address range within the memory pool is available to be allocated for storing new geometry items and a second effective memory pool size in which only a restricted address range within the memory pool is available to be allocated for storing new geometry items, however, Livesley’895 teaches
4. The graphics processor of claim 3, wherein the access logic is operable to select between a first effective memory pool size in which the full address range within the memory pool is available to be allocated for storing new geometry items and a second effective memory pool size in which only a restricted address range within the memory pool is available to be allocated for storing new geometry items. (“... the allocation of memory to each core for geometry processing work depends at least in part on whether that core is processing the lowest active PIM—that is, the PIM having the lowest number of all PIMs currently being processed (and therefore the earliest position in the original geometry sequence)... Memory can therefore be allocated without restriction to the core currently processing the lowest active PIM.”; Livesley’895, [0099], [0100])
When it is determined that the core is performing geometry processing on the lowest active PIM, then memory is allocated without restriction (first effective memory pool size in which the full address range within the memory pool is available to be allocated for storing the new geometry items) to the core currently processing the lowest active PIM. Thus, allocating memory without restriction (first effective memory pool) is selected.
(“... if a core is not processing the lowest active PIM, the allocation of memory to that core for geometry processing work is restricted. In particular, the allocation of memory to such a core may be restricted based at least in part on the amount of currently unrecoverable memory that has already been allocated to the core. Here, unrecoverable memory refers to memory associated with tile control streams for PIMs that are currently not renderable. They are unrenderable because they relate to PIMs “above” (that is, later in the sequence than) the lowest active PIM.”; Livesley’895, [0101])
If a core is not processing the lowest active PIM, then the memory allocated to that core for geometry processing work is restricted (second effective memory pool size in which only a restricted address range within the memory pool is available to be allocated for storing new geometry items). Thus, allocating memory with restriction (second effective memory pool size) is selected.
(“If the master unit 102 determines, in step 440, that the core requesting the memory allocation is currently processing the lowest active PIM, then it allocates the memory without any restriction (in step 450). That is, the master unit 102 allocates the memory in this case without applying any further conditions. If the master unit 102 determines, in step 440, that the request was made by a core other than the core processing the lowest active PIM, there is a restriction on the allocation of the memory. ”; Livesley’895, [0133], Fig. 4)
When the master unit (access logic) determines that the core is currently processing the lowest active PIM, then it allocates memory without any restriction (selects first effective memory pool size). And, when the master unit determines that another core that is processing the another PIM that is not the lowest active PIM, it allocates memory with restriction (selects second effective memory pool size). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Brkic by adding the feature of the access logic is operable to select between a first effective memory pool size in which the full address range within the memory pool is available to be allocated for storing new geometry items and a second effective memory pool size in which only a restricted address range within the memory pool is available to be allocated for storing new geometry items, in order to ensure that the memory is recoverable by a partial render, as taught by Livesley’895 ([0099]).
Re: claims 5 and 15, (which are rejected under the same rationale), Brkic, Livesley and Livesley’895 teach
5. The graphics processor of claim 4, wherein when the effective memory pool size is to be increased from the second effective memory pool size to the first effective memory pool size, the access logic permits allocations for storing new geometry items to be performed within the full address range corresponding to the first effective memory pool size. (“ In our example above, the partial render can include PIM0, PIM1, PIM2 and the part of PIM3 whose geometry processing has been completed so far. The memory allocated to the rendered PIMs can be freed, and reallocated. Note that PIM5-PIM6 cannot be rendered, because this would break the ordering-constraint-fragment processing for these PIMs must be delayed until after fragment processing for PIM3 (and PIM 4) has been completed. This means that the memory allocated in the parameter buffer for PIM5-PIM6 cannot be freed and reused.”; Livesley, [0201])
The size of the memory allocated (memory pool) to the PIMs (PIM0-PIM6) is to be restricted from the first effective memory pool size (which includes PIM0-PIM6) to the second effective memory pool size (which includes PIM5-PIM6). The partial render includes PIM0-PIM2 and part of PIM3, but PIM5-PIM6 cannot be rendered because this would break the ordering constraint for these PIMs. The rendering for PIM5-PIM6 is delayed until after PIM3 and PIM4 have completed processing. Once PIM3-PIM4 have completed processing, PIM5-PIM6 are rendered. The memory allocated to the rendered PIMs can be freed and reallocated. Thus, the memory allocated for PIM5-PIM6 (second memory pool) is freed and reused/reallocated, which increases the memory pool of PIM5-PIM6 (second memory pool) to PIM0-PIM6 (first memory pool) (the effective memory pool size is to be increased from the second effective memory pool size to the first effective memory pool size, the access logic permits allocations for storing new geometry items to be performed within the full address range corresponding to the first effective memory pool size). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Brkic by adding the feature of when the effective memory pool size is to be increased from the second effective memory pool size to the first effective memory pool size, the access logic permits allocations for storing new geometry items to be performed within the full address range corresponding to the first effective memory pool size, in order to use thee available pool of memory as efficiently as possible to avoid situations in which the lack of memory becomes the limiting factor for the continuation of the geometry processing, as taught by Livesley ([0204]).
Re: claims 6 and 16, (which are rejected under the same rationale), Brkic, Livesley and Livesley’895 teach
6. The graphics processor of claim 4, wherein when the effective memory pool size is to be restricted from the first effective memory pool size to the second effective memory pool size, the access logic prevents allocations for storing new geometry items being performed outside of the restricted address range corresponding to the second effective memory pool size, but still permits access to portions of the memory pool outside of the restricted address range that have already been allocated for storing geometry items. (“ In our example above, the partial render can include PIM0, PIM1, PIM2 and the part of PIM3 whose geometry processing has been completed so far. The memory allocated to the rendered PIMs can be freed, and reallocated. Note that PIM5-PIM6 cannot be rendered, because this would break the ordering-constraint-fragment processing for these PIMs must be delayed until after fragment processing for PIM3 (and PIM 4) has been completed. This means that the memory allocated in the parameter buffer for PIM5-PIM6 cannot be freed and reused.”; Livesley, [0201])
The size of the memory allocated (memory pool) to the PIMs (PIM0-PIM6) is to be restricted from the first effective memory pool size (which includes PIM0-PIM6) to the second effective memory pool size (which includes PIM5-PIM6). The partial render includes PIM0-PIM2 and part of PIM3, but PIM5-PIM6 cannot be rendered because this would break the ordering constraint for these PIMs. The rendering for PIM5-PIM6 is delayed until after PIM3 and PIM4 have completed processing. The memory allocated to the rendered PIMs can be freed and reallocated (but still permits access to portions of the memory pool outside of the restricted address range that have already been allocated for storing geometry items). Thus, the memory allocated for PIM5-PIM6 cannot be freed and reused (prevents allocations for storing new geometry items being performed outside of the restricted address range corresponding to the second effective memory pool size). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Brkic by adding the feature of when the effective memory pool size is to be restricted from the first effective memory pool size to the second effective memory pool size, the access logic prevents allocations for storing new geometry items being performed outside of the restricted address range corresponding to the second effective memory pool size, but still permits access to portions of the memory pool outside of the restricted address range that have already been allocated for storing geometry items, in order to use thee available pool of memory as efficiently as possible to avoid situations in which the lack of memory becomes the limiting factor for the continuation of the geometry processing, as taught by Livesley ([0204]).
Allowable Subject Matter
Claims 7, 8, 17 and 18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: None of the prior art teaches or suggests:
From claims 7 and 17 – “wherein the access logic is configured to increase the maximum amount of storage space within the geometry buffer available to be allocated for storing new geometry items produced by the sequence of one or more geometry processing stages when it is determined based on current processing conditions within the graphics processor that the throughput of the binning stage should be increased.” Claims 8 and 18 depend from claims 7 and 17, respectively, and include all of the limitations of claims 7 and 17.
As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONNA J RICKS whose telephone number is (571)270-7532. The examiner can normally be reached on M-F 7:30am-5pm EST (alternate Fridays off).
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, Devona Faulk can be reached on 571-272-7515. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Donna J. Ricks/Examiner, Art Unit 2618
/DEVONA E FAULK/Supervisory Patent Examiner, Art Unit 2618
Prosecution Insights