DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
2. Acknowledgement is made of amendment filed on May 01, 2026, in which claims 1, 10 and 17 are amended, and claims 1-20 are still pending.
Response to Arguments
3. Applicant's arguments, filed on May 01, 2026, with respect to Claims 1-20 have been fully considered and they are not persuasive.
4. With regards to arguments for independent claims 1, 10 and 17, applicants argue that Goel et al. (US 2014/0098117 A1) fails to disclose determining, by the processing device, a processing order for a plurality of instances, the forming including grouping respective said primitives that correspond to respective said polygons together in respective said instances that Goel's processing technique within a graphics pipeline and is selected based on tessellation domain and primitive type. However, the examiner respectfully disagrees and maintains the grounds of rejections regarding claims 1, 10 and 17, since in Goel et al. (US 2014/0098117 A1) teaches (“The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18. In some examples, the software instructions may conform to a graphics application programming interface (API), such as, e.g., an Open Graphics Library (OpenGL.RTM.) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, or any other public or proprietary standard graphics API.” [0058] “graphics pipeline 50 may be configured to perform indexed-based vertex retrieval. In such examples, input assembler 54 may retrieve vertex indexing data for a plurality of primitives to be rendered from a memory (e.g., memory 10 shown in FIGS. 1 and 2 and/or resources block 52 shown in FIG. 3). The vertex indexing data may be indicative of the order in which vertices from a vertex buffer are to be retrieved from the vertex buffer. The vertex indexing data may define a vertex order for each of the primitives to be rendered.” [0104] “In examples where indexed-based vertex retrieval is not used, input assembler 54 may retrieve vertices and/or control points from a vertex buffer in the order in which the vertices are indexed. For example, if the vertex buffer includes an ordered sequence of vertex slots, input assembler 54 may retrieve a first vertex from a first vertex slot in the ordered sequence of vertex slots followed by a second vertex from a second vertex slot in the ordered sequence of vertex slots, etc.” [0106] “A primitive type may refer to a type of primitive that is capable of being received and processed by the graphics processing pipeline. For example, the vertices retrieved by input assembler 54 may be grouped into groups of one or more vertices, and each of these groups of vertices may correspond to a primitive. The primitive type data may indicate the type of primitive associated with each of the groups of vertices and/or associated with the individual vertices within the groups of vertices. For example, the primitive type may define how vertices and/or control points are to be grouped together and/or connected to form a primitive for rendering. As another example, the primitive type may specify how many control points are to be used to define a respective one of the primitives to be rendered.” [0110]) Goel teaches forming groups of primitives corresponding the respect polygons and processing the groups according to a determining order. These groups perform the same function as the claim instances. Therefore, Goel teaches the arguments of the limitations for claims 1, 10 and 17 as it is recited.
Applicants also argue that Gierach et al. (US 2015/0015575 A1) fails to disclose a first polygon, a second polygon and a third polygon of the polygons are rendered consecutively in a Z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon. However, the examiner respectfully disagrees and maintains the grounds of rejections regarding claims 1, 10 and 17, since in Gierach et al. (US 2015/0015575 A1) teaches (“Various embodiments are generally directed to an apparatus, system and method for spatially sorting a plurality of polygons for a scene for rendering by a graphics processing unit (GPU). As previously discussed, polygons are used to create 3-D objects for displaying on a 2-D surface. Triangles are the most common polygon used to create 3-D meshes of the objects, however, the polygon can also be rectangles, hexagons, or other shapes.” [0013] “Various embodiments are not limited to these examples and the 2-D screen space may be divided into any number of sections and the polygons may be added or appended in any order to ensure that overlapping polygons are not consecutively processed.” [0040] “FIG. 3B illustrates another scene with overlapping polygons. More specifically, polygon B overlaps polygon A. … Now all of the polygons are in the sorted list of polygons and they may be processed by the GPU. Various embodiments, are not limited to above example illustrating overlapping polygons, and any number of polygons may overlap any number of other polygons. FIG. 4 illustrates an exemplary embodiment of a top down view of polygons in scene 405 from a viewpoint 407. As shown in depth sorted list 409, the polygons are ordered A, B, C, D and E from back to front to render polygons with transparency correctly. … the polygons may be sorted from front to back to avoid overdraw when rendering an opaque. As shown depth sorted list 413, the polygons are sorted in the order of E, D, C, B and A for front to back order from the viewpoint 407. However, as similarly discussed above with the back to front order, polygon E overlaps polygon D and polygon B overlaps polygon A. To avoid processing the overlapping polygons consecutively and to maintain the relative order of front to back, the polygons may be processed as shown in spatially sorted list 415. More specifically, the polygons may be processed in the following order, E, B, D, A and C to maintain a front to back order and avoid rendering stalls by processing overlapping polygons consecutively.” [0059-0063]) Gierach teaches any number of polygons may overlap any number of other polygons, the polygons may be added or appended in any order. Because the disclosed technique is not limited to a particular number or identity of polygons, polygons A-E can be consider any of first, second and third polygon to process. Gierach further maintains the overlapping polygons according to their relative depth for rendering. Consequently, adjacent polygons in the maintained depth ordering are rendered sequentially, which reasonably teaches the claimed limitation that the first, second, and third polygons are “rendered consecutively in a Z order” under the broadest reasonable interpretation. Therefore, Gierach teaches the arguments of the limitations for claims 1, 10 and 17 as it is recited.
Double Patenting
5. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
6. Claims 1-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-15, 18 and 19 of Patent No. 12,131,418.
Although the conflicting claims are not identical, they are not patentably distinct from each other because they are essentially the same except that claims 1, 10 and 17 of the instant application recites a web browser. However, Goel et al. (US 2014/0098117 A1) teaches this limitation, as discussed below. Thus, claims 1-20 of the instant application is obvious in view of claims 1-15, 18 and 19 of Patent No. 12,131,418.
7. Regarding claim 1, the application claim discloses A method comprising: forming, by a processing device, polygons by tessellating a digital object; defining, by the processing device, a plurality of primitives for each of the polygons; determining, by the processing device, a processing order for a plurality of instances, the forming including grouping respective said primitives that correspond to respective said polygons together in respective said instances; and invoking, by the processing device, the plurality of instances arranged according to the processing order to cause rendering the plurality of primitives in a web browser by a graphics processing unit such that a first polygon, a second polygon and a third polygon of the polygons are rendered consecutively in a z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order. Claim 1 of Patent No. 12,131,418 discloses A method comprising: forming, by a processing device, polygons by tessellating a digital object for rendering the digital object at a second resolution corresponding to a second zoom level different than a first resolution of the digital object corresponding to a first zoom level; defining, by the processing device, a plurality of primitives for each of the polygons; determining, by the processing device, a processing order for a plurality of instances, the forming including grouping respective said primitives that correspond to respective said polygons together in respective said instances; and invoking, by the processing device, the plurality of instances arranged according to the processing order to cause rendering the plurality of primitives by a graphics processing unit such that a first polygon, a second polygon and a third polygon of the polygons are rendered in a z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order, the polygons, including the first polygon, the second polygon, and the third polygon, forming at least a portion of the digital object at the second resolution corresponding to the second zoom level different than the first resolution of the digital object corresponding to the first zoom level. Regarding claim 1, the only difference is that claim 1 of the instant application recites “a web browser” and does not recite “for rendering the digital object at a second resolution corresponding to a second zoom level different than a first resolution of the digital object corresponding to a first zoom level; the polygons, including the first polygon, the second polygon, and the third polygon, forming at least a portion of the digital object at the second resolution corresponding to the second zoom level different than the first resolution of the digital object corresponding to the first zoom level.” while claim 1 of Patent No. 12,131,418 recites. For the additionally limitation, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Goel into Patent No. 12,131,418, in order to reduce the number of times that shader programs need to be reloaded into different processing stages of a graphics pipeline during the rendering of a graphics scene. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention by applicant to modify claim 1 of Patent No. 12,131,418 to include a web browser. ([0058]) Regarding claims 10 and 17, the rationale of claim 1 is applied in rejecting claims 10 and 17. Therefore, the claims in the present application recite a broader scope than the claims in the Patent No. 12,131,418 recite.
8. The following table shows the claims of the current application being examined and the conflicting claims of Patent No. 12,131,418.
Current Application No.
18/890,428
Patent No.
12,131,418
1
1
3-5
2-4
6
5+6
7-9
7-9
10+11
10
12-15
12-15
16
11
17
18
18-20
11-13
The following table shows an example of the corresponding conflicting claims of the current application and Patent No. 12,131,418.
Current Application No.
18/890,428
Claim 1
Patent No.
12,131,418
Claim 1
A method comprising: forming, by a processing device, polygons by tessellating a digital object;
A method comprising: forming, by a processing device, polygons by tessellating a digital object
for rendering the digital object at a second resolution corresponding to a second zoom level different than a first resolution of the digital object corresponding to a first zoom level;
defining, by the processing device, a plurality of primitives for each of the polygons;
defining, by the processing device, a plurality of primitives for each of the polygons;
determining, by the processing device, a processing order for a plurality of instances, the forming including grouping respective said primitives that correspond to respective said polygons together in respective said instances;
determining, by the processing device, a processing order for a plurality of instances, the forming including grouping respective said primitives that correspond to respective said polygons together in respective said instances;
and invoking, by the processing device, the plurality of instances arranged according to the processing order to cause rendering the plurality of primitives by a graphics processing unit such that a first polygon, a second polygon and a third polygon of the polygons are rendered consecutively in a z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order.
and invoking, by the processing device, the plurality of instances arranged according to the processing order to cause rendering the plurality of primitives by a graphics processing unit such that a first polygon, a second polygon and a third polygon of the polygons are rendered in a z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order,
a web browser
Goel teaches this limitation, as discussed above.
the polygons, including the first polygon, the second polygon, and the third polygon, forming at least a portion of the digital object at the second resolution corresponding to the second zoom level different than the first resolution of the digital object corresponding to the first zoom level.
Claim Rejections - 35 USC § 103
9. 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.
10. 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.
11. 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.
12. Claim(s) 1, 2, 5, 6, 8-10 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Labbe et al. (US 2019/0371042 A1) in view of Goel et al. (US 2014/0098117 A1) and Gierach et al. (US 2015/0015575 A1).
13. With reference to claim 1, Labbe teaches A method comprising: forming, by a processing device, polygons by tessellating a digital object; (“FIG. 9A shows a method 900 of operating a semiconductor package apparatus. The method 900 may be implemented as one or more modules in a set of logic instructions …” [0135] “FIG. 9B shows a method 910 of generating a set of polygons.” [0138] “The vertex shader 608 may process vertices of the set of polygons 606 by performing operations such as transformation, skinning, and lighting. The vertex shader 608 may produce the same number of vertices that it takes as input. Additionally, a hull shader 610 (“HS”) may process control points that define a low-order surface such as a line, triangle, or quad. As output, the HS 610 may produce a higher-order geometry “patch” and patch constants that are passed to a fixed-function tessellator 612. The tessellator 612 may pre-process the domain represented by the output of the HS 610. As output, the tessellator 612 may create a sampling pattern of the domain and a set of smaller primitives (e.g., points, lines, triangles) that connect the samples. The illustrated pipeline 600 also includes a domain shader 614 (“DS) that processes higher-order geometry patches from the HS 610 together with the tessellation factors from the tessellator 612. The tessellation factors may include tessellator input factors as well as output factors. As output, the DS 614 may calculate the vertex position of a point on the output patch according the tessellator factors.” [0130]) Labbe also teaches defining, by the processing device, a plurality of primitives for each of the polygons; said primitives that correspond to respective said polygons (“The vertex shader 608 may process vertices of the set of polygons 606 by performing operations such as transformation, skinning, and lighting. The vertex shader 608 may produce the same number of vertices that it takes as input. Additionally, a hull shader 610 (“HS”) may process control points that define a low-order surface such as a line, triangle, or quad. As output, the HS 610 may produce a higher-order geometry “patch” and patch constants that are passed to a fixed-function tessellator 612. The tessellator 612 may pre-process the domain represented by the output of the HS 610. As output, the tessellator 612 may create a sampling pattern of the domain and a set of smaller primitives (e.g., points, lines, triangles) that connect the samples. The illustrated pipeline 600 also includes a domain shader 614 (“DS) that processes higher-order geometry patches from the HS 610 together with the tessellation factors from the tessellator 612. The tessellation factors may include tessellator input factors as well as output factors. As output, the DS 614 may calculate the vertex position of a point on the output patch according the tessellator factors. Additionally, a geometry shader 616 (“GS”) may process entire primitives (e.g., points, lines, or triangles) along with optional vertex data for edge-adjacent primitives. Unlike the VS 608, the GS 616 may produce more or fewer primitives than it takes as input.” [0130-0131])
Labbe does not explicitly teach determining, by the processing device, a processing order for a plurality of instances, the forming including grouping respective said primitives together in respective said instances; and invoking, by the processing device, the plurality of instances arranged according to the processing order to cause rendering the plurality of primitives in a web browser by a graphics processing unit such that a first polygon, a second polygon and a third polygon of the polygons are rendered consecutively in a z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order. This is what Goel teaches. Goel teaches determining, by the processing device, a processing order for a plurality of instances, the forming including grouping respective said primitives together in respective said instances; invoking, by the processing device, the plurality of instances arranged according to the processing order to cause rendering the plurality of primitives in a web browser by a graphics processing unit, (“The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18. In some examples, the software instructions may conform to a graphics application programming interface (API), such as, e.g., an Open Graphics Library (OpenGL.RTM.) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, or any other public or proprietary standard graphics API.” [0058] “graphics pipeline 50 may be configured to perform indexed-based vertex retrieval. In such examples, input assembler 54 may retrieve vertex indexing data for a plurality of primitives to be rendered from a memory (e.g., memory 10 shown in FIGS. 1 and 2 and/or resources block 52 shown in FIG. 3). The vertex indexing data may be indicative of the order in which vertices from a vertex buffer are to be retrieved from the vertex buffer. The vertex indexing data may define a vertex order for each of the primitives to be rendered.” [0104] “In examples where indexed-based vertex retrieval is not used, input assembler 54 may retrieve vertices and/or control points from a vertex buffer in the order in which the vertices are indexed. For example, if the vertex buffer includes an ordered sequence of vertex slots, input assembler 54 may retrieve a first vertex from a first vertex slot in the ordered sequence of vertex slots followed by a second vertex from a second vertex slot in the ordered sequence of vertex slots, etc.” [0106] “A primitive type may refer to a type of primitive that is capable of being received and processed by the graphics processing pipeline. For example, the vertices retrieved by input assembler 54 may be grouped into groups of one or more vertices, and each of these groups of vertices may correspond to a primitive. The primitive type data may indicate the type of primitive associated with each of the groups of vertices and/or associated with the individual vertices within the groups of vertices. For example, the primitive type may define how vertices and/or control points are to be grouped together and/or connected to form a primitive for rendering. As another example, the primitive type may specify how many control points are to be used to define a respective one of the primitives to be rendered.” [0110]) Goel teaches forming groups of primitives corresponding the respect polygons and processing the groups according to a determining order. These groups perform the same function as the claim instances.
PNG
media_image1.png
761
534
media_image1.png
Greyscale
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Goel into Labbe, in order to reduce the number of times that shader programs need to be reloaded into different processing stages of a graphics pipeline during the rendering of a graphics scene.
The combination of Labbe and Goel does not explicitly teach a first polygon, a second polygon and a third polygon of the polygons are rendered consecutively in a z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order. This is what Gierach teaches (“Various embodiments are generally directed to an apparatus, system and method for spatially sorting a plurality of polygons for a scene for rendering by a graphics processing unit (GPU). As previously discussed, polygons are used to create 3-D objects for displaying on a 2-D surface. Triangles are the most common polygon used to create 3-D meshes of the objects, however, the polygon can also be rectangles, hexagons, or other shapes.” [0013] “Various embodiments are not limited to these examples and the 2-D screen space may be divided into any number of sections and the polygons may be added or appended in any order to ensure that overlapping polygons are not consecutively processed.” [0040] “FIG. 3B illustrates another scene with overlapping polygons. More specifically, polygon B overlaps polygon A. … Now all of the polygons are in the sorted list of polygons and they may be processed by the GPU. Various embodiments, are not limited to above example illustrating overlapping polygons, and any number of polygons may overlap any number of other polygons. FIG. 4 illustrates an exemplary embodiment of a top down view of polygons in scene 405 from a viewpoint 407. As shown in depth sorted list 409, the polygons are ordered A, B, C, D and E from back to front to render polygons with transparency correctly. … the polygons may be sorted from front to back to avoid overdraw when rendering an opaque. As shown depth sorted list 413, the polygons are sorted in the order of E, D, C, B and A for front to back order from the viewpoint 407. However, as similarly discussed above with the back to front order, polygon E overlaps polygon D and polygon B overlaps polygon A. To avoid processing the overlapping polygons consecutively and to maintain the relative order of front to back, the polygons may be processed as shown in spatially sorted list 415. More specifically, the polygons may be processed in the following order, E, B, D, A and C to maintain a front to back order and avoid rendering stalls by processing overlapping polygons consecutively.” [0059-0063]) Gierach teaches any number of polygons may overlap any number of other polygons, the polygons may be added or appended in any order. Because the disclosed technique is not limited to a particular number or identity of polygons, polygons A-E can be consider any of first, second and third polygon to process. Gierach further maintains the overlapping polygons according to their relative depth for rendering. Consequently, adjacent polygons in the maintained depth ordering are rendered sequentially, which reasonably teaches the claimed limitation that the first, second, and third polygons are “rendered consecutively in a Z order” under the broadest reasonable interpretation. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gierach into the combination of Labbe and Goel, in order to avoid rendering stalls and performance penalties.
14. With reference to claim 2, Labbe teaches the rendering of the plurality of primitives is part of rendering the digital object as a vector object. (“a graphics pipeline 600 is shown in which a topology shader 602 receives an object description 604 from, for example, a host processor (e.g., central processing unit/CPU), application programming interface (API), driver, and so forth. The object description 604 may include general information as to the type of object to be rendered (e.g., sphere with a certain center and radius, human with a certain skeletal shape, etc.) without specifying the topology of the object to be displayed. The topology shader 602 may receive the object description 604, generate a set of polygons 606 (e.g., triangles, primitives) based on the object description, and send the set of polygons 606 to a vertex shader 608 (“VS”).” [0127] “GPE 1810 includes a 3D pipeline 1812 for performing 3D operations, such as rendering three-dimensional images and scenes using processing functions that act upon 3D primitive shapes (e.g., rectangle, triangle, etc.).” [0199] “each execution unit (e.g. 2108A) is an individual vector processor capable of executing multiple simultaneous threads and processing multiple data elements in parallel for each thread. In some embodiments, execution unit array 2108A-2108N includes any number individual execution units.” [0216])
Labbe does not explicitly teach in the web browser. This is what Goel teaches (“The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18. In some examples, the software instructions may conform to a graphics application programming interface (API), such as, e.g., an Open Graphics Library (OpenGL.RTM.) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, or any other public or proprietary standard graphics API.” [0058]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Goel into Labbe, in order to reduce the number of times that shader programs need to be reloaded into different processing stages of a graphics pipeline during the rendering of a graphics scene.
15. With reference to claim 5, Labbe teaches the digital object is a Bezier curve or a vector object. (“a graphics pipeline 600 is shown in which a topology shader 602 receives an object description 604 from, for example, a host processor (e.g., central processing unit/CPU), application programming interface (API), driver, and so forth. The object description 604 may include general information as to the type of object to be rendered (e.g., sphere with a certain center and radius, human with a certain skeletal shape, etc.) without specifying the topology of the object to be displayed. The topology shader 602 may receive the object description 604, generate a set of polygons 606 (e.g., triangles, primitives) based on the object description, and send the set of polygons 606 to a vertex shader 608 (“VS”).” [0127] “each execution unit (e.g. 2108A) is an individual vector processor capable of executing multiple simultaneous threads and processing multiple data elements in parallel for each thread. In some embodiments, execution unit array 2108A-2108N includes any number individual execution units.” [0216])
16. With reference to claim 6, Labbe teaches the defining defines the plurality of primitives (“Additionally, a hull shader 610 (“HS”) may process control points that define a low-order surface such as a line, triangle, or quad. As output, the HS 610 may produce a higher-order geometry “patch” and patch constants that are passed to a fixed-function tessellator 612. The tessellator 612 may pre-process the domain represented by the output of the HS 610. As output, the tessellator 612 may create a sampling pattern of the domain and a set of smaller primitives (e.g., points, lines, triangles) that connect the samples. The illustrated pipeline 600 also includes a domain shader 614 (“DS) that processes higher-order geometry patches from the HS 610 together with the tessellation factors from the tessellator 612. The tessellation factors may include tessellator input factors as well as output factors. As output, the DS 614 may calculate the vertex position of a point on the output patch according the tessellator factors. Additionally, a geometry shader 616 (“GS”) may process entire primitives (e.g., points, lines, or triangles) along with optional vertex data for edge-adjacent primitives. Unlike the VS 608, the GS 616 may produce more or fewer primitives than it takes as input. The pipeline 600 may also include a pixel shader 618 (“PS”) that processes rasterized primitives together with interpolated vertex data to generate per-pixel values such as color and depth.” [0130-0131])
Labbe does not explicitly teach using coordinate positions and respective colors in a vertex buffer and wherein the vertex buffer is accessible to the graphics processing unit. This is what Goel teaches. Goel teaches using coordinate positions and respective colors in a vertex buffer (“Commands 40 may include one or more state commands and/or one or more draw call commands. A state command may instruct GPU 12 to change one or more of the state variables in GPU 12, such as, e.g., the draw color. A draw call command may instruct GPU 12 to render the geometry defined by a group of one or more vertices 36 (e.g., defined in a vertex buffer) stored in memory 10. The geometry defined by the group of one or more vertices 36 may, in some examples, correspond to a plurality of primitives to be rendered.” [0090] “Input assembler 54 is configured to retrieve a plurality vertices from one or more vertex buffers, and to output the vertices to vertex shader 56 for further processing. The one or more vertex buffers may be stored in a memory (e.g., memory 10 shown in FIGS. 1 and 2 and/or resources block 52 shown in FIG. 3). The vertices and/or control points may correspond to one or more primitives to be rendered. Each of vertices may include one or more attributes, such as, e.g., positional coordinates, normal coordinates, texture coordinates, etc.” [0103]) Goel also teaches the vertex buffer is accessible to the graphics processing unit. (“the API may allow a user to specify different primitive types for different vertices to be rendered. In some examples, the API may also include instructions and/or data structures that allow a user application to place data indicative of the primitive type for each of the vertices to be processed during a draw call instruction into one or more buffers (e.g., vertex buffers) that are accessible by the GPU. In additional examples, the API may include a state command that instructs the GPU to execute a draw call command based on the data indicative of the primitive type for each of the vertices to be processed.” [0043]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Goel into Labbe, in order to reduce the number of times that shader programs need to be reloaded into different processing stages of a graphics pipeline during the rendering of a graphics scene.
17. With reference to claim 8, Labbe does not explicitly teach the invoking is performed as a batch that includes the plurality of instances using a single draw call. This is what Goel teaches (“input assembler 54 may retrieve a first vertex index corresponding to a first vertex to be retrieved from a vertex buffer, and may retrieve the first vertex from a first location (e.g., a first vertex slot) in the vertex buffer that is identified by the first vertex index. After retrieving the first vertex in this example, input assembler 54 may retrieve a second vertex index corresponding to a second vertex to be retrieved from a vertex buffer, and may retrieve the second vertex from a second location (e.g., a second vertex slot) in the vertex buffer that is identified by the second vertex index. Using indexed rendering may allow out-of-order access to vertices in a vertex buffer (i.e., vertices to be retrieved in a different order than the order in which such vertices were indexed). Using indexed-based vertex retrieval may allow the vertices in a vertex buffer to be accessed in an out-of-order fashion, which may reduce the complexity of vertex buffer generation by a graphics application. In addition, using indexed-based vertex retrieval may allow the same vertex to be retrieved multiple times from a vertex buffer during a single draw call, which may reduce memory footprint requirements for a particular draw call.” [0105] “rasterizer 66 may be configured to select a rasterization technique from a plurality of rasterization techniques based on a rasterization primitive type received from a different processing stage in graphics pipeline 50. For example, rasterizer may 66 select a first rasterization technique from the plurality of rasterization techniques if the rasterization primitive type is a first rasterization primitive type, and select a second rasterization technique from the plurality rasterization techniques if the rasterization primitive type is a second rasterization primitive type. The first rasterization primitive type may be different than the second rasterization primitive type. The first rasterization technique may be the same as or different than the second rasterization technique. Allowing rasterizer 66 to rasterize rasterization primitives of different rasterization primitive types during a single draw call may enable the graphics pipeline to render input primitives that map to different rasterization primitive types during a single draw call.” [0144]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Goel into Labbe, in order to reduce the number of times that shader programs need to be reloaded into different processing stages of a graphics pipeline during the rendering of a graphics scene.
18. With reference to claim 9, Labbe does not explicitly teach the rendering is performed by the graphics processing unit to a frame buffer. This is what Goel teaches (“CPU 6 and/or GPU 12 may store rendered image data in a frame buffer that is allocated within system memory 10. Display interface 16 may retrieve the data from the frame buffer and configure display 18 to display the image represented by the rendered image data. In some examples, display interface 16 may include a digital-to-analog converter (DAC) that is configured to convert the digital values retrieved from the frame buffer into an analog signal consumable by display 18.” [0065] “for each pixel received from rasterizer 66, pixel shader 68 may execute an instance of a pixel shader program on a shader unit of GPU 12. … Output merger 70 may place pixel data received from pixel shader 68 into a render target (e.g., a frame buffer).” [0147-0149]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Goel into Labbe, in order to reduce the number of times that shader programs need to be reloaded into different processing stages of a graphics pipeline during the rendering of a graphics scene.
19. Claim 10 is similar in scope to claim 1, and thus is rejected under similar rationale. Labbe additionally teaches A system comprising: a central processing unit configured to perform operations, a graphics processing unit (“the one or more parallel processor(s) 112 incorporate circuitry optimized for graphics and video processing, including, for example, video output circuitry, and constitutes a graphics processing unit (GPU). In another embodiment, the one or more parallel processor(s) 112 incorporate circuitry optimized for general purpose processing, while preserving the underlying computational architecture, described in greater detail herein. In yet another embodiment, components of the computing system 100 may be integrated with one or more other system elements on a single integrated circuit.” [0035] “the techniques described herein may be implemented on any properly configured processing unit, including, without limitation, one or more mobile application processors, one or more desktop or server central processing units (CPUs) including multi-core CPUs, one or more parallel processing units, such as the parallel processing unit 202 of FIG. 2, as well as one or more graphics processors or special purpose processing units, without departure from the scope of the embodiments described herein. In some embodiments a parallel processor or GPGPU as described herein is communicatively coupled to host/processor cores to accelerate graphics operations, machine-learning operations, pattern analysis operations, and various general purpose GPU (GPGPU) functions. The GPU may be communicatively coupled to the host processor/cores over a bus or other interconnect (e.g., a high speed interconnect such as PCIe or NVLink).” [0071-0072])
Labbe does not explicitly teach a single draw call, and a frame buffer, and a web browser configured to render the polygons, including the first polygon, the second polygon, and the third polygon in the z order, in a display device. This is what Goel teaches. Goel teaches a single draw call, and a frame buffer, and a web browser configured to render (“The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18. In some examples, the software instructions may conform to a graphics application programming interface (API), such as, e.g., an Open Graphics Library (OpenGL.RTM.) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, or any other public or proprietary standard graphics API.” [0058] “graphics pipeline 50 may be configured to perform indexed-based vertex retrieval. In such examples, input assembler 54 may retrieve vertex indexing data for a plurality of primitives to be rendered from a memory (e.g., memory 10 shown in FIGS. 1 and 2 and/or resources block 52 shown in FIG. 3). The vertex indexing data may be indicative of the order in which vertices from a vertex buffer are to be retrieved from the vertex buffer. The vertex indexing data may define a vertex order for each of the primitives to be rendered.” [0104] “Allowing rasterizer 66 to rasterize rasterization primitives of different rasterization primitive types during a single draw call may enable the graphics pipeline to render input primitives that map to different rasterization primitive types during a single draw call.” [0144] “for each pixel received from rasterizer 66, pixel shader 68 may execute an instance of a pixel shader program on a shader unit of GPU 12. … Output merger 70 may place pixel data received from pixel shader 68 into a render target (e.g., a frame buffer).” [0147-0149]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Goel into Labbe, in order to reduce the number of times that shader programs need to be reloaded into different processing stages of a graphics pipeline during the rendering of a graphics scene.
The combination of Labbe and Goel does not explicitly teach the polygons, including the first polygon, the second polygon, and the third polygon in the z order, in a display device. This is what Gierach teaches (“Various embodiments are generally directed to an apparatus, system and method for spatially sorting a plurality of polygons for a scene for rendering by a graphics processing unit (GPU). As previously discussed, polygons are used to create 3-D objects for displaying on a 2-D surface. Triangles are the most common polygon used to create 3-D meshes of the objects, however, the polygon can also be rectangles, hexagons, or other shapes.” [0013] “Various embodiments are not limited to these examples and the 2-D screen space may be divided into any number of sections and the polygons may be added or appended in any order to ensure that overlapping polygons are not consecutively processed.” [0040] “FIG. 3B illustrates another scene with overlapping polygons. More specifically, polygon B overlaps polygon A. … Now all of the polygons are in the sorted list of polygons and they may be processed by the GPU. Various embodiments, are not limited to above example illustrating overlapping polygons, and any number of polygons may overlap any number of other polygons. FIG. 4 illustrates an exemplary embodiment of a top down view of polygons in scene 405 from a viewpoint 407. As shown in depth sorted list 409, the polygons are ordered A, B, C, D and E from back to front to render polygons with transparency correctly. … the polygons may be sorted from front to back to avoid overdraw when rendering an opaque. As shown depth sorted list 413, the polygons are sorted in the order of E, D, C, B and A for front to back order from the viewpoint 407. However, as similarly discussed above with the back to front order, polygon E overlaps polygon D and polygon B overlaps polygon A. To avoid processing the overlapping polygons consecutively and to maintain the relative order of front to back, the polygons may be processed as shown in spatially sorted list 415. More specifically, the polygons may be processed in the following order, E, B, D, A and C to maintain a front to back order and avoid rendering stalls by processing overlapping polygons consecutively.” [0059-0063]) Gierach teaches any number of polygons may overlap any number of other polygons, the polygons may be added or appended in any order, and the polygons A-E can be consider any of first, second and third polygon to process and render. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gierach into the combination of Labbe and Goel, in order to avoid rendering stalls and performance penalties.
20. With reference to claim 16, Labbe does not explicitly teach the determining and the invoking are performed as part of executing a browser by the central processing unit. This is what Goel teaches (“The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18. In some examples, the software instructions may conform to a graphics application programming interface (API), such as, e.g., an Open Graphics Library (OpenGL.RTM.) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, or any other public or proprietary standard graphics API.” [0058] “graphics pipeline 50 may be configured to perform indexed-based vertex retrieval. In such examples, input assembler 54 may retrieve vertex indexing data for a plurality of primitives to be rendered from a memory (e.g., memory 10 shown in FIGS. 1 and 2 and/or resources block 52 shown in FIG. 3). The vertex indexing data may be indicative of the order in which vertices from a vertex buffer are to be retrieved from the vertex buffer. The vertex indexing data may define a vertex order for each of the primitives to be rendered.” [0104] “for each pixel received from rasterizer 66, pixel shader 68 may execute an instance of a pixel shader program on a shader unit of GPU 12. … Output merger 70 may place pixel data received from pixel shader 68 into a render target (e.g., a frame buffer).” [0147-0149]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Goel into Labbe, in order to reduce the number of times that shader programs need to be reloaded into different processing stages of a graphics pipeline during the rendering of a graphics scene.
21. Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Labbe et al. (US 2019/0371042 A1), Goel et al. (US 2014/0098117 A1) and Gierach et al. (US 2015/0015575 A1), as applied to claim 1 above, and further in view of Movshovich et al. (US 2003/0193506 A1).
22. With reference to claim 3, Labbe teaches the defining forms for the polygons of the digital object. (“a graphics pipeline 600 is shown in which a topology shader 602 receives an object description 604 from, for example, a host processor (e.g., central processing unit/CPU), application programming interface (API), driver, and so forth. The object description 604 may include general information as to the type of object to be rendered (e.g., sphere with a certain center and radius, human with a certain skeletal shape, etc.) without specifying the topology of the object to be displayed. The topology shader 602 may receive the object description 604, generate a set of polygons 606 (e.g., triangles, primitives) based on the object description, and send the set of polygons 606 to a vertex shader 608 (“VS”).” [0127])
The combination of Labbe, Goel and Gierach does not explicitly teach an antialiasing spread. This is what Movshovich teaches (“At the start of the line, new primitives for the line are loaded into the processors 24, via step 62. The primitives are loaded from the internal memory 22 to the processors 24. Thus, primitives which commenced at a previous line and which will contribute to the current line remain in the processors 24. The line is then processed, via step 64. Step 64 may include performing interpolation, texture processing, antialiasing or other operations used in rendering the scene.” [0023]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Movshovich into the combination of Labbe, Goel and Gierach, in order to more efficiently utilize the processors of a computer graphics system.
23. Claim(s) 4 and 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Labbe et al. (US 2019/0371042 A1), Goel et al. (US 2014/0098117 A1) and Gierach et al. (US 2015/0015575 A1), as applied to claim 1 above, and further in view of Beri et al. (US 2018/0033168 A1).
24. With reference to claim 4, the combination of Labbe, Goel and Gierach does not explicitly teach the defining includes expanding each of the polygons formed as triangles into the plurality of primitives formed as triangles through geometry amplification. This is what Beri teaches (“an expansion module expands the control tiles based on the control tile descriptors. Interior control tiles are forwarded along the graphics pipeline to bypass the anti-aliasing procedure. Each of the curves corresponding to exterior control tiles are anti-aliased, but individual exterior control tiles are treated differently depending on the type of curve. Triangle-shaped control tiles are used below to describe an example of the fourth stage of the anti-aliasing pipeline. The expansion module includes a transformation module and an enlargement module. The transformation module transforms each exterior control triangle into an expanded control polygon that spreads out the pixel coverage for anti-aliasing. In some embodiments, the expanded control polygon is implemented as a rectangle with 90-degree angles to facilitate computation within the GPU.” [0040]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Beri into the combination of Labbe, Goel and Gierach, in order to reduce the jagged appearance.
25. With reference to claim 7, the combination of Labbe, Goel and Gierach does not explicitly teach detecting whether the polygons formed from tessellating the digital object are interior triangles or control triangles of the digital object and wherein the forming is performed for the polygons that are control triangles and not for the polygons that are interior triangles. This is what Beri teaches (“Within the GPU 204, the interior control tiles are forwarded along the graphics rendering pipeline 206 to bypass the anti-aliasing procedure (e.g., interior control tiles can be passed through the geometry shader 214 unchanged). In the fourth stage 310, an expansion module 326 expands the exterior control tiles based on the control tile descriptors. The fourth stage 310 can be implemented in conjunction with (e.g., along with or as part of) the tessellation shader 212 or the geometry shader 214 of the graphics rendering pipeline 206. A triangular control tile is used herein as an example shape for the control tiles to describe operation of the expansion module 326;” [0075] “The example filled Bezier path is substantially a circle. With the circle 402 on the left, the fill has been omitted to reveal an example tessellation of the circle into numerous control triangles. Any of many known tessellation algorithms may be employed to tessellate a filled Bezier path. For example, Vatti's algorithm may be used to realize a tessellation engine that produces two kinds of triangles—those that are located in the interior of the Bezier path and those that are located along the exterior. As shown, the interior control triangles are white, and the exterior control triangles are shaded light grey.” [0080]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Beri into the combination of Labbe, Goel and Gierach, in order to reduce the jagged appearance.
26. Claim(s) 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Labbe et al. (US 2019/0371042 A1) in view of Goel et al. (US 2014/0098117 A1), Movshovich et al. (US 2003/0193506 A1) and Gierach et al. (US 2015/0015575 A1).
27. With reference to claim 17, Labbe teaches One or more computer-readable storage media storing instructions that, responsive to execution by a processing device, causes the processing device to perform operations (“the one or more parallel processor(s) 112 incorporate circuitry optimized for graphics and video processing, including, for example, video output circuitry, and constitutes a graphics processing unit (GPU). In another embodiment, the one or more parallel processor(s) 112 incorporate circuitry optimized for general purpose processing, while preserving the underlying computational architecture, described in greater detail herein. In yet another embodiment, components of the computing system 100 may be integrated with one or more other system elements on a single integrated circuit.” [0035] “FIG. 9A shows a method 900 of operating a semiconductor package apparatus. The method 900 may be implemented as one or more modules in a set of logic instructions stored in a non-transitory machine- or computer-readable storage medium …” [0135] “the method 910 may be implemented as one or more modules in a set of logic instructions stored in a non-transitory machine- or computer-readable storage medium” [0138]) Labbe also teaches forming polygons by tessellating a vector object for rendering the vector object; (“FIG. 9B shows a method 910 of generating a set of polygons.” [0138] “The vertex shader 608 may process vertices of the set of polygons 606 by performing operations such as transformation, skinning, and lighting. The vertex shader 608 may produce the same number of vertices that it takes as input. Additionally, a hull shader 610 (“HS”) may process control points that define a low-order surface such as a line, triangle, or quad. As output, the HS 610 may produce a higher-order geometry “patch” and patch constants that are passed to a fixed-function tessellator 612. The tessellator 612 may pre-process the domain represented by the output of the HS 610. As output, the tessellator 612 may create a sampling pattern of the domain and a set of smaller primitives (e.g., points, lines, triangles) that connect the samples. The illustrated pipeline 600 also includes a domain shader 614 (“DS) that processes higher-order geometry patches from the HS 610 together with the tessellation factors from the tessellator 612. The tessellation factors may include tessellator input factors as well as output factors. As output, the DS 614 may calculate the vertex position of a point on the output patch according the tessellator factors.” [0130] “each execution unit (e.g. 2108A) is an individual vector processor capable of executing multiple simultaneous threads and processing multiple data elements in parallel for each thread. In some embodiments, execution unit array 2108A-2108N includes any number individual execution units.” [0216]) Labbe further teaches defining a plurality of primitives for each of the polygons; said primitives that correspond to respective said polygons (“The vertex shader 608 may process vertices of the set of polygons 606 by performing operations such as transformation, skinning, and lighting. The vertex shader 608 may produce the same number of vertices that it takes as input. Additionally, a hull shader 610 (“HS”) may process control points that define a low-order surface such as a line, triangle, or quad. As output, the HS 610 may produce a higher-order geometry “patch” and patch constants that are passed to a fixed-function tessellator 612. The tessellator 612 may pre-process the domain represented by the output of the HS 610. As output, the tessellator 612 may create a sampling pattern of the domain and a set of smaller primitives (e.g., points, lines, triangles) that connect the samples. The illustrated pipeline 600 also includes a domain shader 614 (“DS) that processes higher-order geometry patches from the HS 610 together with the tessellation factors from the tessellator 612. The tessellation factors may include tessellator input factors as well as output factors. As output, the DS 614 may calculate the vertex position of a point on the output patch according the tessellator factors. Additionally, a geometry shader 616 (“GS”) may process entire primitives (e.g., points, lines, or triangles) along with optional vertex data for edge-adjacent primitives. Unlike the VS 608, the GS 616 may produce more or fewer primitives than it takes as input.” [0130-0131])
Labbe does not explicitly teach in a web browser; generating an antialiasing spread; determining a processing order by grouping said primitives together in respective instances of a plurality of instances; and invoking a single draw call to a graphics processing unit to render the vector object, the single draw call including the plurality of instances arranged according to the processing order such that a first polygon, a second polygon and a third polygon of the polygons are rendered consecutively in a z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order. This is what Goel teaches. Goel teaches in a web browser; determining a processing order by grouping said primitives together in respective instances of a plurality of instances; and invoking a single draw call to a graphics processing unit to render the vector object, the single draw call including the plurality of instances arranged according to the processing order, (“The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18. In some examples, the software instructions may conform to a graphics application programming interface (API), such as, e.g., an Open Graphics Library (OpenGL.RTM.) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, or any other public or proprietary standard graphics API.” [0058] “graphics pipeline 50 may be configured to perform indexed-based vertex retrieval. In such examples, input assembler 54 may retrieve vertex indexing data for a plurality of primitives to be rendered from a memory (e.g., memory 10 shown in FIGS. 1 and 2 and/or resources block 52 shown in FIG. 3). The vertex indexing data may be indicative of the order in which vertices from a vertex buffer are to be retrieved from the vertex buffer. The vertex indexing data may define a vertex order for each of the primitives to be rendered.” [0104] “In examples where indexed-based vertex retrieval is not used, input assembler 54 may retrieve vertices and/or control points from a vertex buffer in the order in which the vertices are indexed. For example, if the vertex buffer includes an ordered sequence of vertex slots, input assembler 54 may retrieve a first vertex from a first vertex slot in the ordered sequence of vertex slots followed by a second vertex from a second vertex slot in the ordered sequence of vertex slots, etc.” [0106] “A primitive type may refer to a type of primitive that is capable of being received and processed by the graphics processing pipeline. For example, the vertices retrieved by input assembler 54 may be grouped into groups of one or more vertices, and each of these groups of vertices may correspond to a primitive. The primitive type data may indicate the type of primitive associated with each of the groups of vertices and/or associated with the individual vertices within the groups of vertices. For example, the primitive type may define how vertices and/or control points are to be grouped together and/or connected to form a primitive for rendering. As another example, the primitive type may specify how many control points are to be used to define a respective one of the primitives to be rendered.” [0110] “Allowing rasterizer 66 to rasterize rasterization primitives of different rasterization primitive types during a single draw call may enable the graphics pipeline to render input primitives that map to different rasterization primitive types during a single draw call.” [0144] “for each pixel received from rasterizer 66, pixel shader 68 may execute an instance of a pixel shader program on a shader unit of GPU 12. … Output merger 70 may place pixel data received from pixel shader 68 into a render target (e.g., a frame buffer).” [0147-0149]) Goel teaches forming groups of primitives corresponding the respect polygons and processing the groups according to a determining order. These groups perform the same function as the claim instances.
PNG
media_image1.png
761
534
media_image1.png
Greyscale
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Goel into Labbe, in order to reduce the number of times that shader programs need to be reloaded into different processing stages of a graphics pipeline during the rendering of a graphics scene.
The combination of Labbe and Goel does not explicitly teach generating an antialiasing spread; a first polygon, a second polygon and a third polygon of the polygons are rendered consecutively in a z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order. This is what Movshovich teaches. Movshovich teaches generating an antialiasing spread; (“At the start of the line, new primitives for the line are loaded into the processors 24, via step 62. The primitives are loaded from the internal memory 22 to the processors 24. Thus, primitives which commenced at a previous line and which will contribute to the current line remain in the processors 24. The line is then processed, via step 64. Step 64 may include performing interpolation, texture processing, antialiasing or other operations used in rendering the scene.” [0023]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Movshovich into the combination of Labbe and Goel, in order to more efficiently utilize the processors of a computer graphics system.
The combination of Labbe, Goel and Movshovich does not explicitly teach a first polygon, a second polygon and a third polygon of the polygons are rendered consecutively in a z order with the second polygon overlapping the first polygon and the third polygon overlapping the second polygon, the first polygon, the second polygon and the third polygon respectively corresponding to a first instance, a second instance and a third instance of the plurality of instances arranged according to the processing order. This is what Gierach teaches (“Various embodiments are generally directed to an apparatus, system and method for spatially sorting a plurality of polygons for a scene for rendering by a graphics processing unit (GPU). As previously discussed, polygons are used to create 3-D objects for displaying on a 2-D surface. Triangles are the most common polygon used to create 3-D meshes of the objects, however, the polygon can also be rectangles, hexagons, or other shapes.” [0013] “Various embodiments are not limited to these examples and the 2-D screen space may be divided into any number of sections and the polygons may be added or appended in any order to ensure that overlapping polygons are not consecutively processed.” [0040] “FIG. 3B illustrates another scene with overlapping polygons. More specifically, polygon B overlaps polygon A. … Now all of the polygons are in the sorted list of polygons and they may be processed by the GPU. Various embodiments, are not limited to above example illustrating overlapping polygons, and any number of polygons may overlap any number of other polygons. FIG. 4 illustrates an exemplary embodiment of a top down view of polygons in scene 405 from a viewpoint 407. As shown in depth sorted list 409, the polygons are ordered A, B, C, D and E from back to front to render polygons with transparency correctly. … the polygons may be sorted from front to back to avoid overdraw when rendering an opaque. As shown depth sorted list 413, the polygons are sorted in the order of E, D, C, B and A for front to back order from the viewpoint 407. However, as similarly discussed above with the back to front order, polygon E overlaps polygon D and polygon B overlaps polygon A. To avoid processing the overlapping polygons consecutively and to maintain the relative order of front to back, the polygons may be processed as shown in spatially sorted list 415. More specifically, the polygons may be processed in the following order, E, B, D, A and C to maintain a front to back order and avoid rendering stalls by processing overlapping polygons consecutively.” [0059-0063]) Gierach teaches any number of polygons may overlap any number of other polygons, the polygons may be added or appended in any order. Because the disclosed technique is not limited to a particular number or identity of polygons, polygons A-E can be consider any of first, second and third polygon to process. Gierach further maintains the overlapping polygons according to their relative depth for rendering. Consequently, adjacent polygons in the maintained depth ordering are rendered sequentially, which reasonably teaches the claimed limitation that the first, second, and third polygons are “rendered consecutively in a Z order” under the broadest reasonable interpretation. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Gierach into the combination of Labbe, Goel and Movshovich, in order to avoid rendering stalls and performance penalties.
28. With reference to claim 18, Labbe does not explicitly teach the determining and the invoking are performed as part of executing a browser by the central processing unit. This is what Goel teaches (“The software applications that execute on CPU 6 may include one or more graphics rendering instructions that instruct GPU 12 to cause the rendering of graphics data to display 18. In some examples, the software instructions may conform to a graphics application programming interface (API), such as, e.g., an Open Graphics Library (OpenGL.RTM.) API, an Open Graphics Library Embedded Systems (OpenGL ES) API, a Direct3D API, an X3D API, a RenderMan API, a WebGL API, or any other public or proprietary standard graphics API.” [0058] “graphics pipeline 50 may be configured to perform indexed-based vertex retrieval. In such examples, input assembler 54 may retrieve vertex indexing data for a plurality of primitives to be rendered from a memory (e.g., memory 10 shown in FIGS. 1 and 2 and/or resources block 52 shown in FIG. 3). The vertex indexing data may be indicative of the order in which vertices from a vertex buffer are to be retrieved from the vertex buffer. The vertex indexing data may define a vertex order for each of the primitives to be rendered.” [0104] “for each pixel received from rasterizer 66, pixel shader 68 may execute an instance of a pixel shader program on a shader unit of GPU 12. … Output merger 70 may place pixel data received from pixel shader 68 into a render target (e.g., a frame buffer).” [0147-0149]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Goel into Labbe, in order to reduce the number of times that shader programs need to be reloaded into different processing stages of a graphics pipeline during the rendering of a graphics scene.
29. With reference to claim 19, Labbe teaches the central processing unit is further configured to perform operations including forming the respective polygons by tessellating a digital object and defining the primitives for each of the respective polygons. (“a graphics pipeline 600 is shown in which a topology shader 602 receives an object description 604 from, for example, a host processor (e.g., central processing unit/CPU), application programming interface (API), driver, and so forth. The object description 604 may include general information as to the type of object to be rendered (e.g., sphere with a certain center and radius, human with a certain skeletal shape, etc.) without specifying the topology of the object to be displayed. The topology shader 602 may receive the object description 604, generate a set of polygons 606 (e.g., triangles, primitives) based on the object description, and send the set of polygons 606 to a vertex shader 608 (“VS”).” [0127] “The vertex shader 608 may process vertices of the set of polygons 606 by performing operations such as transformation, skinning, and lighting. The vertex shader 608 may produce the same number of vertices that it takes as input. Additionally, a hull shader 610 (“HS”) may process control points that define a low-order surface such as a line, triangle, or quad. As output, the HS 610 may produce a higher-order geometry “patch” and patch constants that are passed to a fixed-function tessellator 612. The tessellator 612 may pre-process the domain represented by the output of the HS 610. As output, the tessellator 612 may create a sampling pattern of the domain and a set of smaller primitives (e.g., points, lines, triangles) that connect the samples. The illustrated pipeline 600 also includes a domain shader 614 (“DS) that processes higher-order geometry patches from the HS 610 together with the tessellation factors from the tessellator 612. The tessellation factors may include tessellator input factors as well as output factors. As output, the DS 614 may calculate the vertex position of a point on the output patch according the tessellator factors. Additionally, a geometry shader 616 (“GS”) may process entire primitives (e.g., points, lines, or triangles) along with optional vertex data for edge-adjacent primitives. Unlike the VS 608, the GS 616 may produce more or fewer primitives than it takes as input.” [0130-0131])
30. With reference to claim 20, Labbe teaches the defining forms for the respective polygons of the digital object. (“a graphics pipeline 600 is shown in which a topology shader 602 receives an object description 604 from, for example, a host processor (e.g., central processing unit/CPU), application programming interface (API), driver, and so forth. The object description 604 may include general information as to the type of object to be rendered (e.g., sphere with a certain center and radius, human with a certain skeletal shape, etc.) without specifying the topology of the object to be displayed. The topology shader 602 may receive the object description 604, generate a set of polygons 606 (e.g., triangles, primitives) based on the object description, and send the set of polygons 606 to a vertex shader 608 (“VS”).” [0127])
The combination of Labbe and Goel does not explicitly teach an antialiasing spread. This is what Movshovich teaches (“At the start of the line, new primitives for the line are loaded into the processors 24, via step 62. The primitives are loaded from the internal memory 22 to the processors 24. Thus, primitives which commenced at a previous line and which will contribute to the current line remain in the processors 24. The line is then processed, via step 64. Step 64 may include performing interpolation, texture processing, antialiasing or other operations used in rendering the scene.” [0023]) Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Movshovich into the combination of Labbe and Goel, in order to more efficiently utilize the processors of a computer graphics system.
Conclusion
31. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Michelle Chin whose telephone number is (571)270-3697. The examiner can normally be reached on Monday-Friday 8:00 AM-4:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kent Chang can be reach on (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 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 http://pair-direct.uspto.gov. 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.
/MICHELLE CHIN/
Primary Examiner, Art Unit 2614
Prosecution Insights