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 .
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1 – 2, 7 – 8, 11, and 16 – 17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Nickolls et al. US Patent Application Publication No. 2011/0074802 (herein after referred to as Nickolls).
Regarding claim 1, Nickolls describes a graphics processor comprising: an instruction execution resource (The SPM 310 functional units include N exec (execution or processing) units 302… (page 5, paragraph [0054])); a cache memory coupled with the instruction execution resource (The L1 cache 320 (which surface instructions use)… (page 7, paragraph [0070])); and memory access circuitry coupled with the instruction execution resource and the cache memory (load-store units (LSU) 303 (page 5, paragraph [0054])), the memory access circuitry configured to: receive a request to access pixel data at a location on a surface, the surface including pixel data having a specified pixel format, wherein the request includes a coordinate of the location on the surface and an identifier for the surface (Fig. 6 is a flow diagram of method steps for a compute application program to use a surface instruction to access a multi-dimensional formatted graphics surface, according to one embodiment of the present invention… At step 610, the x and y coordinates are extracted from the surface instruction. At step 615, the surface format information is used… (page 9, paragraph [0085]). Various properties of a surface influence how the surface is stored. The properties include the size (in samples) in each dimension, a component mask describing which components exist in a surface, the size of each sample (in bytes), the format of a pixel, the surface layout (pitch or block linear) and pitch dimensions or block size, the rank (1D, array of 1D, 2D, array of 2D, 3D), base address, and surface identifier (ID number), handle, or pointer to the surface descriptor (page 7, paragraph [0064]). The surface instructions take a surface identifier operand as a register or immediate. Surface load/store instruction operands specify a data destination/source register vector, the format of the register, the surface identifier register or immediate, an x, y, z coordinate register vector, and small, signed offsets for each dimension (page 7, paragraph [0074])); generate a virtual address for the pixel data based at least in part on the coordinate of the location of the surface and one or more elements of surface state data for the surface (At step 615, the surface format information is used to convert the x and y coordinates into a generic address. At step 620, the generic address is converted into a physical memory address (via a virtual address) (page 9, paragraph [0085])); and store the pixel data at a location in the cache memory, the location in the cache memory determined at least in part based on the virtual address generated for the pixel data (At step 625, samples corresponding to the x and y coordinates are used to access the multi-dimensional format surface (page 9, paragraph [0085]). The instruction stores data from operand c to the surface named by operand a at coordinates given by operand b. Operand a is a surface identifier. Coordinate operand b… is a two-element vector for 2d surfaces… (page 9, paragraph [0092])).
Regarding claim 2, Nickolls describes the graphics processor of claim 1 (see above), wherein the cache memory is a level one (L1) cache (The L1 cache 320 (which surface instructions use)… (page 7, paragraph [0070])).
Regarding claim 7, Nickolls describes the graphics processor of claim 1 (see above), the identifier for the surface to enable retrieval of the surface state data (The SUQ surface instruction queries a surface attribute of a multi-dimension surface. Operand a is a surface identifier… (page 10, paragraph [0109])).
Regarding claim 8, Nickolls describes the graphics processor of claim 7 (see above), further comprising a surface state cache to store surface state data for the surface, the memory access circuitry configured to retrieve the surface state data from the surface state cache based at least in part on the identifier for the surface (The SUQ surface instruction queries a surface attribute of a multi-dimension surface. Operand a is a surface identifier… SUQ may query additional surface attributes, including sample data format, sample size, component mask, and tiling block size (page 10, paragraph [0109]). The disclosed “surface attributes” may reasonably be interpreted as “surface state data”, as they are attributes of the surface which can describe the state of said surface. The attributes are returned in response to the query instruction. Where the attributes are returned from may be interpreted as the “surface state cache” since the previously identified “surface state data” resides at this location).
Regarding claim 11, Nickolls describes a method comprising: receiving, at memory access circuitry of a graphics processor, a request to access pixel data at a location on a surface in memory, the surface including pixel data having a specified pixel format, wherein the request includes a coordinate of the location on the surface and an identifier for the surface (Fig. 6 is a flow diagram of method steps for a compute application program to use a surface instruction to access a multi-dimensional formatted graphics surface, according to one embodiment of the present invention… At step 610, the x and y coordinates are extracted from the surface instruction. At step 615, the surface format information is used… (page 9, paragraph [0085]). Various properties of a surface influence how the surface is stored. The properties include the size (in samples) in each dimension, a component mask describing which components exist in a surface, the size of each sample (in bytes), the format of a pixel, the surface layout (pitch or block linear) and pitch dimensions or block size, the rank (1D, array of 1D, 2D, array of 2D, 3D), base address, and surface identifier (ID number), handle, or pointer to the surface descriptor (page 7, paragraph [0064]). The surface instructions take a surface identifier operand as a register or immediate. Surface load/store instruction operands specify a data destination/source register vector, the format of the register, the surface identifier register or immediate, an x, y, z coordinate register vector, and small, signed offsets for each dimension (page 7, paragraph [0074])); retrieving surface state data for the surface based on the identifier for the surface (The SUQ surface instruction queries a surface attribute of a multi-dimension surface. Operand a is a surface identifier… (page 10, paragraph [0109])); generating a virtual address for the pixel data based at least in part on the coordinate of the location of the surface and one or more elements of the surface state data for the surface (At step 615, the surface format information is used to convert the x and y coordinates into a generic address. At step 620, the generic address is converted into a physical memory address (via a virtual address) (page 9, paragraph [0085])); and storing the pixel data at a location in a cache memory associated with the memory access circuitry, the location in the cache memory determined at least in part based on the virtual address generated for the pixel data (At step 625, samples corresponding to the x and y coordinates are used to access the multi-dimensional format surface (page 9, paragraph [0085]). The instruction stores data from operand c to the surface named by operand a at coordinates given by operand b. Operand a is a surface identifier. Coordinate operand b… is a two-element vector for 2d surfaces… (page 9, paragraph [0092])).
Regarding claim 16, Nickolls describes a data processing system comprising: a memory device (…local parallel processing memory 204 (which can be used as graphics memory including, e.g., a conventional frame buffer) to store and update pixel data, delivering pixel data to display device 110… (page 2, paragraph [0027])); and a graphics processor coupled with the memory device (…the parallel processing subsystem 112 incorporates circuitry optimized for graphics and video processing, including, for example, video output circuitry, and constitutes a graphics processing unit (GPU) (page 2, paragraph [0024]). …some or all of PPUs 202 in parallel processing subsystem 112 are graphics processors with rendering pipelines that can be configured to perform various tasks related to generating pixel data from graphics data supplied by CPU 102 and/or system memory 104 via memory bridge 105 and bus 113… (page 2, paragraph [0027])), the graphics processor comprising: an instruction execution resource (The SPM 310 functional units include N exec (execution or processing) units 302… (page 5, paragraph [0054])); a cache memory coupled with the instruction execution resource to cache data associated with the memory device (The L1 cache 320 (which surface instructions use)… (page 7, paragraph [0070])); and memory access circuitry coupled with the instruction execution resource and the cache memory (load-store units (LSU) 303 (page 5, paragraph [0054])), the memory access circuitry configured to: receive a request to access pixel data at a location on a surface stored in the memory device, the surface including pixel data having a specified pixel format, wherein the request includes a coordinate of the location on the surface and an identifier for the surface (Fig. 6 is a flow diagram of method steps for a compute application program to use a surface instruction to access a multi-dimensional formatted graphics surface, according to one embodiment of the present invention… At step 610, the x and y coordinates are extracted from the surface instruction. At step 615, the surface format information is used… (page 9, paragraph [0085]). Various properties of a surface influence how the surface is stored. The properties include the size (in samples) in each dimension, a component mask describing which components exist in a surface, the size of each sample (in bytes), the format of a pixel, the surface layout (pitch or block linear) and pitch dimensions or block size, the rank (1D, array of 1D, 2D, array of 2D, 3D), base address, and surface identifier (ID number), handle, or pointer to the surface descriptor (page 7, paragraph [0064]). The surface instructions take a surface identifier operand as a register or immediate. Surface load/store instruction operands specify a data destination/source register vector, the format of the register, the surface identifier register or immediate, an x, y, z coordinate register vector, and small, signed offsets for each dimension (page 7, paragraph [0074])); generate a virtual address for the pixel data based at least in part on the coordinate of the location of the surface and one or more elements of surface state data for the surface (At step 615, the surface format information is used to convert the x and y coordinates into a generic address. At step 620, the generic address is converted into a physical memory address (via a virtual address) (page 9, paragraph [0085])); and store the pixel data at a location in the cache memory, the location in the cache memory determined at least in part based on the virtual address generated for the pixel data (At step 625, samples corresponding to the x and y coordinates are used to access the multi-dimensional format surface (page 9, paragraph [0085]). The instruction stores data from operand c to the surface named by operand a at coordinates given by operand b. Operand a is a surface identifier. Coordinate operand b… is a two-element vector for 2d surfaces… (page 9, paragraph [0092])).
Regarding claim 17, Nickolls describes the data processing system of claim 16 (see above), wherein the cache memory is a level one (L1) cache (The L1 cache 320 (which surface instructions use)… (page 7, paragraph [0070])).
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.
Claims 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Nickolls in view of McAllister et al. US Patent Application Publication No. 2012/0050303 (herein after referred to as McAllister).
Regarding claim 9, Nickolls describes the graphics processor of claim 8 (see above). Nickolls does not specify that the one or more elements of surface state data for the surface to include a number of bits per pixel, a number of channels, and a number of bits per channel.
McAllister describes a system for the lossless compression of color data. Specifically, it is disclosed that the compression state 605 is stored in the control unit 605 and includes information specifying the compression format of different render targets, e.g., graphics surfaces, stored in graphics memory. The compression state 382 also stores information specifying the color depth, color format, and pixel sample mode for each render target. Examples of some possible color depth values include 8, 16, 24, 32, 64, 128 bits per sample of a pixel, each sample may contain up to four channels. The channels may represent red, green, blue, alpha, luminance, chrominance, saturation, and the like. The different channels may be represented in different formats, such as signed or unsigned integer or floating point values. Finally, different sampling modes specify one or more sub-pixel samples per pixel and positions of the sub-pixel samples within the pixel as well as the number of color values that are shared between two or more samples (page 8, paragraph [0079]).
Therefore, it would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to incorporate the McAllister teachings in the Nickolls system. Skilled artisan would have been motivated to incorporate the method of storing information specifying color depth, color format and pixel sample mode as taught by McAllister in the Nickolls system for effectively storing graphics information in a lossless format. In addition, both of the references teach features that are directed to analogous art and they are directed to the same field of endeavor, such as storage of graphics surfaces. This close relation between both of the references highly suggests an expectation of success.
Regarding claim 10, Nickolls in view of McAllister describe the graphics processor of claim 9 (see above), wherein the one or more elements of surface state data for the surface includes a surface dimensionality properties for the surface (SUQ may query additional surface attributes, including sample data format, sample size, component mask, and tiling block size (Nickolls, page 11, paragraph [0109])).
Allowable Subject Matter
Claims 3 – 6, 12 – 15, and 18 – 20 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: Claim 3 describes “the graphics processor of claim 2, wherein the virtual address generated for the pixel data is a first address and the memory access circuitry is configured to: after the pixel data is stored to the cache memory based on the first address, determine a second address for the pixel data; generate a map between the first address and the second address; and store the map between the first address and the second address to a location that is accessible to the memory access circuitry.” Claims 12 and 18 include similar limitations. Nickolls discloses that a memory management unit includes a set of page table entries used to map a virtual address to a physical address of a tile and optionally a cache line index (page 4, paragraph [0045]). Furthermore, at step 620 the generic address is converted into a physical memory address (via a virtual address) (page 9, paragraph [0085]). However, Nickolls does not explicitly teach or suggest after the pixel data is stored to the cache memory based on the first address, determine a second address for the pixel data; generate a map between the first address and the second address; and store the map between the first address and the second address to a location that is accessible to the memory access circuitry. Heinrich et al. US Patent Application Publication No. 2015/0046662 describes that texture processing circuitry is extended to support load/store memory accesses including load/store accesses of surfaces stored in memory. Furthermore, Heinrich discloses that the address is output to a virtual address generation unit to convert coordinates and/or relative addresses into virtual addresses (or physical memory addresses). The virtual address is then stored into the address. The virtual address generation unit may be configured to generate the virtual address for a coalesce buffer entry in parallel with the filling of the coalesce buffer entry. However, Heinrich does not explicitly teach or suggest after the pixel data is stored to the cache memory based on the first address, determine a second address for the pixel data; generate a map between the first address and the second address; and store the map between the first address and the second address to a location that is accessible to the memory access circuitry. Naoi US Patent Application Publication No. 2008/0313434 describes a rendering processing apparatus, parallel processing apparatus, and exclusive control method. Furthermore, Naoi discloses that a lock cache caches lock information on a pixel in association with a logical address, where the logical address corresponds to the pixel coordinates (x, y). However, Naoi does not explicitly teach or suggest after the pixel data is stored to the cache memory based on the first address, determine a second address for the pixel data; generate a map between the first address and the second address; and store the map between the first address and the second address to a location that is accessible to the memory access circuitry. Jiao et al. US Patent Application Publication No. 2008/0074430 describes graphics processing unit with unified vertex cache and shader register file. Specifically, GPU includes a virtual address map that maps vertex cache locations and virtual register addresses to physical addresses within unified storage. Unified vertex cache and shader register file includes reference count storage and a storage release module. Virtual address map includes a reference count update module. However, Jiao does not explicitly teach or suggest after the pixel data is stored to the cache memory based on the first address, determine a second address for the pixel data; generate a map between the first address and the second address; and store the map between the first address and the second address to a location that is accessible to the memory access circuitry. Liang et al. US Patent Application Publication No. 2016/0321774 describes adaptive memory address scanning based on surface format for graphics processing. Specifically, MMU of MIF may determine the physical addresses that correspond to the virtual addresses, and GPU through MIF may store the pixel values at the pages of memory system that correspond to the physical addresses. However, Liang does not explicitly teach or suggest after the pixel data is stored to the cache memory based on the first address, determine a second address for the pixel data; generate a map between the first address and the second address; and store the map between the first address and the second address to a location that is accessible to the memory access circuitry. Berger et al. US Patent Application Publication No. 2022/0222771 describes multi-directional rolling cache and methods therefor. Specifically, the page tables list virtual to external memory physical address mapping to improve performance and may be stored on external memory/storage device. However, Berger does not explicitly teach or suggest after the pixel data is stored to the cache memory based on the first address, determine a second address for the pixel data; generate a map between the first address and the second address; and store the map between the first address and the second address to a location that is accessible to the memory access circuitry. Iourcha et al. US Patent No. 9378560 describes real time on-chip texture decompression using shader processors. Specifically, table may map the virtual address space of texture to the physical address space of compressed texture. However, Iourcha does not explicitly teach or suggest after the pixel data is stored to the cache memory based on the first address, determine a second address for the pixel data; generate a map between the first address and the second address; and store the map between the first address and the second address to a location that is accessible to the memory access circuitry.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RALPH A VERDERAMO III whose telephone number is (571)270-1174. The examiner can normally be reached Monday through Friday 8:30 AM - 5:00 PM.
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, Reginald Bragdon can be reached at (571) 272-4204. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RALPH A VERDERAMO III/Examiner, Art Unit 2139
/REGINALD G BRAGDON/Supervisory Patent Examiner, Art Unit 2139
rv
February 7, 2026