Techniques for stochastic texture filtering through single instruction multiple threads and single instruction multiple data lane communication
Stochastic texture filtering with SIMT/SIMD architectures addresses computing resource issues in conventional methods, reducing visual artifacts and maintaining low overhead while enhancing rendering quality through efficient texel sharing.
Patent Information
- Application Number
- DE102025130602
- Authority / Receiving Office
- DE · DE
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-04-01
- Filing Date
- 2025-08-01
- Publication Date
- 2026-02-19
AI Technical Summary
Conventional texture filtering techniques using AI or machine learning-based algorithms require significant computing resources, leading to visual distortions and inefficiencies, especially during texture scaling and advanced lighting effects, and lack efficient texture sample sharing.
Implement stochastic texture filtering with Single Instruction Multiple Threads (SIMT) and Single Instruction Multiple Data (SIMD) architectures, using filter footprints to stochastically sample texels and enable inter-thread communication for efficient texel sharing across neighboring pixels.
Reduces visual artifacts and noise, improves rendering quality under magnification and nonlinear shading, and maintains low computational overhead by facilitating efficient texture sample reuse.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
CROSS-REFERENCE TO RELATED REGISTRATIONS
[0001] This application claims priority over the preliminary US patent application entitled “STOCHASTIC TEXTURE FILTERING QUAD / WAVE COMMUNICATION”, filed on August 14, 2024, with serial number 63 / 683,150, and the preliminary US patent application entitled “STOCHASTIC TEXTURE FILTERING THROUGH SINGLE INSTRUCTION MULTIPLE THREADS AND SINGLE INSTRUCTION MULTIPLE DATA LANE COMMUNICATION”, filed on December 13, 2024, with serial number 63 / 733,962. The subject matter of these related applications is hereby incorporated by reference herein. BACKGROUND Area of the various implementation examples
[0002] Embodiments of the present disclosure generally relate to computer science and computer graphics, and in particular to techniques for stochastic texture filtering by Single Instruction Multiple Threads and Single Instruction Multiple Data Lane communication. Description of the related technique
[0003] Texture filtering is a technique in computer graphics that involves reconstructing texels to render arbitrary textured surfaces within an image. Traditional texture filtering techniques, such as bilinear or trilinear filtering, use predictable, step-by-step procedures known as deterministic algorithms to sample and interpolate texels to calculate the colors of pixels within an image. While these techniques are well-suited for hardware-accelerated implementations, where specialized graphics hardware, such as graphics processing units (GPUs), performs the texture filtering, traditional texture filtering techniques face limitations when using artificial intelligence (AI) or machine learning-based algorithms, such as neural texture compression (NTC), to reduce texture sizes during the rendering process.In particular, conventional texture filtering techniques that use AI or machine learning-based algorithms typically require significant computing resources, which can limit their practicality in real-time video games, large-scale visualizations, and other applications that require fast and reliable processing.
[0004] Stochastic Texture Filtering (STF) was developed to mitigate the drawbacks of the aforementioned texture filtering techniques that use AI or machine learning-based algorithms by providing a random selection approach to texels, rather than relying on GPU assistance in hardware-accelerated implementations. Unlike traditional techniques that rely on predictable, step-by-step processes to display textures, STF introduces a controlled amount of randomness into the process to improve how textures appear in rendered images. This added randomness helps prevent common visual problems, such as blurriness that occurs when the image appears indistinct or fuzzy, or unwanted repeating patterns that appear unrealistic when textures are zoomed in or viewed from different perspectives in the final rendered images.
[0005] One disadvantage of STF is that, under certain conditions, it can introduce unwanted visual distortions that may reduce the overall quality of the rendered image. For example, if a texture needs to be greatly enlarged (also known as texture scaling) to fit a larger area or screen, STF can produce visual noise and artifacts. Similarly, when advanced lighting effects are applied, such as those that simulate how light interacts with surfaces to create depth and detail on a flat surface (also known as normal mapping) or how light is brightly reflected from shiny surfaces (also known as specular lighting), STF can sometimes cause visual flaws or bright spots. These issues can reduce the overall quality of the displayed image.
[0006] Another disadvantage of NTC and similar methods is that decompressed texel values are not cached, preventing efficient sharing between neighboring pixels during operations such as scaling. Additionally, NTC and similar methods decompress using software running on the GPU, rather than dedicated texture decompression hardware, resulting in increased computational overhead.
[0007] As the above illustrates, more effective texture filtering techniques are needed in this field. SUMMARY
[0008] An embodiment of the present disclosure presents a computer-implemented method for rendering graphic images. The method includes, for each lane contained in a plurality of lanes within a wave (i.e., a thread group on a processing unit that synchronously executes the same instruction stream on different input data), sampling a texel based on a filter to generate a texel sample. The method further includes, for each lane contained in the plurality of lanes, calculating a filtered value based on a plurality of texel samples read by a corresponding plurality of lanes, based on a footprint (i.e., a sample pattern, i.e., an area within the texture) associated with the lane.Additionally, the process includes rendering at least one section of a graphic image based on the filtered values calculated for the multitude of lanes.
[0009] Other embodiments of the present disclosure include, without limitation, one or more computer-readable media containing instructions for carrying out one or more aspects of the disclosed techniques, and one or more computer systems for carrying out one or more aspects of the disclosed techniques.
[0010] At least one technical advantage of the disclosed techniques compared to the prior art is that they reduce visual artifacts and noise typically associated with stochastic texture filtering compared to conventional filtering approaches, particularly under magnification conditions or when nonlinear shading, such as normal imaging or specular highlights, is present. By facilitating the efficient sharing and reuse of texture samples across neighboring pixels, the disclosed techniques can be used to generate images that are relatively close in appearance to images produced using hardware filters.Furthermore, the disclosed techniques can achieve rendering improvements while maintaining relatively low computational overhead, including no additional texture look-up costs compared to conventional STF. These technical advantages represent one or more technological improvements over state-of-the-art approaches. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] To better understand the features of the various embodiments mentioned above, a more precise description of the inventive concepts summarized above can be obtained by referring to several embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings represent only typical embodiments of the inventive concepts and are therefore in no way intended to limit the scope, and that other equally effective embodiments exist. Fig. Figure 1 is a block diagram illustrating a computer system configured to implement one or more aspects of the present embodiments; Fig. 2 is a block diagram of a parallel processing unit located in the parallel processing subsystem of Fig. 1 is included, according to various embodiments; Fig. Figure 3 is a block diagram of a general processing cluster located in the parallel processing unit of Fig. 2 is included, according to various embodiments; Fig. Figure 4 is a block diagram illustrating an exemplary cloud computer system, according to various implementation examples; Fig. Figure 5 illustrates how texture filtering can be performed using deterministic square footprints and pseudorandom sparse footprints for texel sharing within a wave, according to various embodiments; Fig. Figure 6 illustrates two exemplary techniques for defining 2×2 footprints in a wave of size 16, arranged as a 4×4 grid of lanes, according to different embodiments; Fig. Figure 7 illustrates exemplary texture filtering results produced using various techniques, according to different implementation examples; Fig. Figure 8 is a more detailed illustration of the footprint generator from Fig. 1, according to various embodiments; Fig. Figure 9 is a flowchart of process steps for generating and optimizing pseudorandom footprints for texel sharing within a wave, according to various embodiments; and Fig. Figure 10 is a flowchart of process steps for performing rendering with texel sharing between lanes, according to various embodiments. DETAILED DESCRIPTION
[0012] The following description presents numerous specific details to provide a more thorough understanding of the various embodiments. However, it is obvious to a person skilled in the art that the inventive concepts can be implemented without one or more of these specific details. General overview
[0013] Embodiments of the present disclosure provide techniques for improving texture filtering by using stochastic sampling in conjunction with inter-thread communication in graphics processing units (GPUs). In some embodiments, a rendering application stochastically samples a first texel using a filter footprint that spans multiple threads or processing lanes, which may be implemented in software and / or hardware. The filter footprint, which may be square or pseudorandom in design, defines which pixels in a wave can be accessed to retrieve previously calculated values, such as weights or texel values.For example, a square footprint with a square configuration accesses the pixels in the wave, while a pseudorandom footprint introduces controlled random sampling to minimize regular sampling patterns that can lead to artifacts. The rendering application uses the filter footprint to access additional texels from neighboring threads using inter-thread communication enabled by the Single Instruction Multiple Threads (SIMT) and / or Single Instruction Multiple Data (SIMD) architectures in a GPU. The rendering application then assigns a weight to each texel sample, calculated using a probability distribution function (PDF) that shows the probability of sampling that texel based on the filter footprint.The application normalizes the weights and applies the normalized weights to each texel to calculate a weighted average, which can then be used to calculate a pixel color.
[0014] The texture filtering techniques of this disclosure have many real-world applications. For example, texture filtering techniques can be used during the rendering of an image or the frames of a video. Another example is the use of texture filtering techniques during the rendering of frames in a video game.
[0015] The examples above are not intended to be limiting in any way. As those skilled in the art will recognize, the texture filtering techniques described herein can generally be implemented in any application where texture filtering is required or useful. System overview
[0016] Fig. Figure 1 is a block diagram illustrating a computer system 100 configured to implement one or more aspects of the present embodiments. As the person skilled in the art will recognize, the computer system 100 can comprise any type of technically feasible computer system, including, without limitation, a server machine, a server platform, a desktop machine, a laptop machine, a handheld / mobile device, or a portable device. In some embodiments, the computer system 100 is a server machine operating in a data center or cloud computing environment that provides scalable computing resources as a service over a network.
[0017] In various embodiments, the computer system 100 comprises, without limitation, a central processing unit (CPU) 102 and a system memory 104, which is coupled to a parallel processing subsystem 112 via a memory bridge 105 and a communication path 113. The memory bridge 105 is further coupled to an I / O (input / output) bridge 107 via a communication path 106, and the I / O bridge 107 is in turn coupled to a switch 116.
[0018] In one embodiment, the I / O bridge 107 is configured to receive user input information from optional input devices 108, such as a keyboard or mouse, and to forward the input information to the CPU 102 for processing via the communication path 106 and the memory bridge 105. In some embodiments, the computer system 100 may be a server machine in a cloud computing environment. In such embodiments, the computer system 100 may not have the input devices 108. Instead, the computer system 100 may receive equivalent input information by receiving commands in the form of messages transmitted over a network and received via the network adapter 118.In one embodiment, the switch 116 is configured to provide connections between the I / O bridge 107 and other components of the computer system 100, such as a network adapter 118 and various add-in cards 120 and 121.
[0019] In one embodiment, the I / O bridge 107 is coupled to a system disk 114, which can be configured to store content, applications, and data for use by the CPU 102 and the parallel processing subsystem 112. In one embodiment, the system disk 114 provides non-volatile memory for applications and data and can include fixed or removable hard disk drives, flash memory devices, and CD-ROM (Compact Disc Read-Only Memory), DVD-ROM (Digital Versatile Disc-ROM), Blu-ray, HD-DVD (High-Definition DVD), or other magnetic, optical, or solid-state storage devices. In other embodiments, other components, such as Universal Serial Bus or other port connections, Compact Disc drives, Digital Versatile Disc drives, movie recording devices, and the like, can also be connected to the I / O bridge 107.
[0020] In various embodiments, the memory bridge 105 can be a northbridge chip, and the I / O bridge 107 can be a southbridge chip. Additionally, the communication paths 106 and 113, as well as other communication paths within the computer system 100, can be implemented using any technically suitable protocols, including, without limitation, AGP (Accelerated Graphics Port), HyperTransport, or any other bus or point-to-point communication protocol known in the art.
[0021] In some embodiments, the parallel processing subsystem 112 comprises a graphics subsystem that supplies pixels to an optional display device 110, which may be any conventional cathode ray tube, liquid crystal display, light-emitting diode display, or the like. In such embodiments, the parallel processing subsystem 112 includes circuits optimized for graphics and video processing, including, for example, video output circuits. As described below in conjunction with Fig. 2- Fig. As described in more detail in Section 3, such circuits can be integrated via one or more parallel processing units (PPUs), also referred to herein as parallel processors, contained in the parallel processing subsystem 112. In other embodiments, the parallel processing subsystem 112 comprises circuits optimized for general-purpose and / or computational processing. Again, such circuits can be integrated via one or more PPUs contained in the parallel processing subsystem 112 configured to perform such general-purpose and / or computational operations. In still other embodiments, the one or more PPUs contained in the parallel processing subsystem 112 can be configured to perform graphics processing, general-purpose, and computational processing operations.System memory 104 includes at least one device driver 103 configured to manage the processing operations of one or more PPUs within the parallel processing subsystem 112. Additionally, system memory 104 includes a footprint generator 128 and a rendering application 130. The footprint generator 128 is an application that generates sets of pseudorandom footprints for use in the texture filtering techniques disclosed herein, as described below in conjunction with [reference to relevant section]. Fig. 5- Fig. 9 described. The rendering application 130 can be any technically feasible application that renders virtual three-dimensional (3D) scenes using the texture filtering techniques disclosed herein. For example, the rendering application 130 could be a game application or a rendering application used in film production. Although described herein mainly in relation to the footprint generator 128 and the rendering application 130, techniques disclosed herein may also be implemented, either wholly or partially, in other software and / or hardware, such as the parallel processing subsystem 112.
[0022] In various embodiments, the parallel processing subsystem 112 can be combined with one or more of the other elements of Fig. 1. can be integrated to form a single system. For example, the parallel processing subsystem 112 can be integrated with the CPU 102 and other interconnect circuitry on a single chip to form a system-on-chip (SoC).
[0023] In one embodiment, the CPU 102 is the main processor of the computer system 100, controlling and coordinating the operations of other system components. In another embodiment, the CPU 102 issues instructions that control the operation of PPUs. In some embodiments, the communication path 113 is a PCI Express connection in which dedicated lanes are assigned to each PPU, as is known in the art. The PPU advantageously implements a highly parallel processing architecture. A PPU can be provided with any amount of local parallel processing memory (PP memory).
[0024] It is understood that the system shown herein is for illustrative purposes only and that variations and modifications are possible. The connection topology, including the number and arrangement of bridges, the number of CPUs 102, and the number of parallel processing subsystems 112, can be modified as desired. For example, in some embodiments, the system memory 104 could be connected directly to the CPU 102 instead of via the memory bridge 105, and other devices would communicate with the system memory 104 via the memory bridge 105 and the CPU 102. In other embodiments, the parallel processing subsystem 112 could be connected to the I / O bridge 107 or directly to the CPU 102 instead of the memory bridge 105. In still other embodiments, the I / O bridge 107 and the memory bridge 105 could be integrated into a single chip instead of existing as one or more discrete devices.In certain embodiments, one or more components that are in . Fig. The components shown in Figure 1 may not be present. For example, the switch 116 could be omitted, and the network adapter 118 and the add-in cards 120 and 121 would connect directly to the I / O bridge 107. Finally, in certain embodiments, one or more components shown in Figure 1 may be omitted. Fig. The resources shown in Figure 1 can be implemented as virtualized resources in a virtual computing environment, such as a cloud computing environment. In particular, the parallel processing subsystem 112 can be implemented as a virtualized parallel processing subsystem in some embodiments. For example, the parallel processing subsystem 112 could be implemented as a virtual graphics processing unit (GPU) that renders graphics on a virtual machine (VM) running on a server machine whose GPU and other physical resources are shared across multiple VMs.
[0025] Fig. Figure 2 is a block diagram of a parallel processing unit (PPU) 202, which is part of the parallel processing subsystem 112 of Fig. 1 is included, according to various embodiments. Although Fig. Since Figure 2 represents a PPU 202, as indicated above, the parallel processing subsystem 112 can comprise any number of PPUs 202. As shown, the PPU 202 is coupled to a local parallel processing memory (PP memory) 204. The PPU 202 and the PP memory 204 can be implemented using one or more integrated circuit devices, such as programmable processors, application-specific integrated circuits (ASICs), or memory devices, or in any other technically feasible manner.
[0026] In some embodiments, the PPU 202 includes a GPU that can be configured to implement a graphics rendering pipeline to perform various operations related to generating pixel data based on graphics data provided by the CPU 102 and / or the system memory 104. When processing graphics data, the PP memory 204 can be used as graphics memory, storing one or more conventional frame buffers and, if required, one or more other render targets. Among other things, the PP memory 204 can be used to store and update pixel data and deliver final pixel data or display frames to an optional display device 110 for display. In some embodiments, the PPU 202 can also be configured for general-purpose processing and computational operations.In some embodiments, the computer system 100 may be a server machine in a cloud computing environment. In such embodiments, the computer system 100 may not have a display device 110. Instead, the computer system 100 may generate equivalent output information by transmitting commands in the form of messages over a network via the network adapter 118.
[0027] In some embodiments, the CPU 102 is the main processor of the computer system 100, controlling and coordinating the operations of other system components. In one embodiment, the CPU 102 issues instructions that control the operation of the PPU 202. In some embodiments, the CPU 102 writes a stream of instructions for the PPU 202 to a data structure (not explicitly shown in Fig. 1 or Fig. 2), which may reside in system memory 104, PP memory 204, or another memory location accessible to both CPU 102 and PPU 202. A pointer to the data structure is written to an instruction queue, also referred to herein as a push buffer, to initiate the processing of the stream of instructions in the data structure. In one embodiment, PPU 202 reads instruction streams from the instruction queue and then executes instructions asynchronously with respect to the operation of CPU 102. In embodiments where multiple push buffers are created, execution priorities for each push buffer can be specified by an application program via a device driver to control the scheduling of the different push buffers.
[0028] In one embodiment, the PPU 202 comprises an I / O (input / output) unit 205, which communicates with the rest of the computer system 100 via the communication path 113 and the memory bridge 105. In this embodiment, the I / O unit 205 generates packets (or other signals) for transmission on the communication path 113 and also receives all incoming packets (or other signals) from the communication path 113, routing the incoming packets to appropriate components of the PPU 202. For example, commands relating to processing tasks can be routed to a host interface 206, while commands relating to memory operations (e.g., reading from or writing to the PP memory 204) can be routed to a crossbar unit 210. In one embodiment, the host interface 206 reads each command queue and transmits the command stream stored in the command queue to a front-end 212.
[0029] As above in connection with Fig. As mentioned in Section 1, the connection of the PPU 202 to the rest of the computer system 100 can be varied. In some embodiments, the parallel processing subsystem 112, which includes at least one PPU 202, is implemented as an add-in card that can be inserted into an expansion slot of the computer system 100. In other embodiments, the PPU 202 can be integrated on a single chip with a bus bridge, such as the memory bridge 105 or the I / O bridge 107. In still other embodiments, some or all of the elements of the PPU 202 can be included together with the CPU 102 in a single integrated circuit or system-of-chip (SoC).
[0030] In one embodiment, the front-end 212 transfers processing tasks received from the host interface 206 to a workload distribution unit (not shown) within the task / work unit 207. In this embodiment, the workload distribution unit receives pointers to processing tasks encoded as task metadata (TMD) and stored in memory. The pointers to TMDs are contained in an instruction stream, stored as an instruction queue, which is received by the front-end unit 212 from the host interface 206. Processing tasks, which may be encoded as TMDs, contain indices associated with the data to be processed, as well as state parameters and instructions that define how the data is to be processed. For example, the state parameters and instructions could define the program to be executed on the data.The TMD could also, for example, specify the number and configuration of the set of CTAs. Generally, each TMD corresponds to a task. The task / work unit 207 receives tasks from the front end 212 and ensures that general processing clusters (GPCs) 208 are configured to a valid state before initiating the processing task specified by each TMD. A priority can be specified for each TMD, which is used to schedule the execution of the processing task. Processing tasks can also be received from the processing cluster array 230. Optionally, the TMD can include a parameter that controls whether the TMD is added to the head or the end of a list of processing tasks (or to a list of pointers to the processing tasks), thus providing another level of control over the execution priority.
[0031] In one embodiment, the PPU 202 implements a highly parallel processing architecture based on a processing cluster array 230, which comprises a set of C GPCs 208, where C ≥ 1. Each GPC 208 is capable of executing a large number (e.g., hundreds or thousands) of threads concurrently, with each thread being an instance of a program. In different applications, different GPCs 208 can be allocated to process different types of programs or to perform different types of computations. The allocation of GPCs 208 can vary depending on the workload generated by each type of program or computation.
[0032] In one embodiment, the memory interface 214 comprises a set of D partition units 215, where D ≥ 1. Each partition unit 215 is coupled to one or more dynamic random access memories (DRAMs) 220 located within the PPM memory 204. In some embodiments, the number of partition units 215 is equal to the number of DRAMs 220, and each partition unit 215 is coupled to a different DRAM 220. In other embodiments, the number of partition units 215 may differ from the number of DRAMs 220. Those skilled in the art will recognize that a DRAM 220 can be replaced by any other technically suitable storage device.During operation, various rendering targets, such as texture images and frame buffers, can be stored across DRAMs 220, enabling the partition units 215 to write sections of each rendering target in parallel to efficiently utilize the available bandwidth of the PP memory 204.
[0033] In one embodiment, a given GPC 208 can process data to be written to each of the DRAMs 220 within the PP memory 204. In one embodiment, the crossbar unit 210 is configured to route the output of each GPC 208 to the input of each partition unit 215 or to any other GPC 208 for further processing. The GPCs 208 communicate with the memory interface 214 via the crossbar unit 210 to read from or write to different DRAMs 220. In some embodiments, in addition to a connection to the PP memory 204 via the memory interface 214, the crossbar unit 210 has a connection to the I / O unit 205, enabling the processing cores within the different GPCs 208 to communicate with the system memory 104 or other memory that is not local to the PPU 202. In the embodiment of Fig. In 2, the crossbar unit 210 is directly connected to the I / O unit 205. In various embodiments, the crossbar unit 210 can use virtual channels to separate traffic flows between the GPCs 208 and the partition units 215.
[0034] In one embodiment, the GPCs 208 can be programmed to perform processing tasks related to a wide variety of applications, including, without limitation, linear and nonlinear data transformations, filtering of video and / or audio data, modeling operations (e.g., applying laws of physics to determine the position, velocity, and other attributes of objects), image rendering operations (e.g., tessellation shaders, vertex shaders, geometry shaders, and / or pixel / fragment shader programs), general arithmetic operations, etc. In operation, the PPU 202 is configured to transfer data from system memory 104 and / or PP memory 204 to one or more on-chip memory units, process the data, and write the resulting data back to system memory 104 and / or PP memory 204.The result data can then be accessed by other system components, including CPU 102, another PPU 202 within the parallel processing subsystem 112, or another parallel processing subsystem 112 within the computer system 100.
[0035] In one embodiment, any number of PPUs 202 can be contained in a parallel processing subsystem 112. For example, multiple PPUs 202 can be provided on a single add-in card, or multiple add-in cards can be connected to the communication path 113, or one or more of the PPUs 202 can be integrated into a bridge chip. The PPUs 202 in a multi-PPU system can be identical or different from one another. For example, different PPUs 202 could have a different number of processing cores and / or different amounts of PP memory 204. In implementations where multiple PPUs 202 are present, these PPUs can be operated in parallel to process data at a higher throughput than is possible with a single PPU 202.Systems containing one or more PPUs 202 can be implemented in a variety of configurations and form factors, including, without limitation, desktops, laptops, handheld personal computers or other handheld devices, portable devices, servers, workstations, game consoles, embedded systems and the like.
[0036] Fig. Figure 3 is a block diagram of a general processing cluster (GPC) 208, which is located in the parallel processing unit (PPU) 202 of Fig. 2 is included, according to various embodiments. As shown, the GPC 208 includes, without limitation, a pipeline manager 305, one or more texture units 315, a PreROP unit 325, a work distribution crossbar 330, and an L1.5 cache 335.
[0037] In one embodiment, the GPC 208 can be configured to run a large number of threads in parallel to perform graphics, general processing, and / or computational operations. As used herein, a "thread" refers to an instance of a particular program running on a specific set of input data. Some embodiments employ Single-Instruction, Multiple-Data (SIMD) instruction output techniques to support the parallel execution of a large number of threads without providing multiple independent instruction units.In other embodiments, single-instruction, multiple-thread (SIMT) techniques are used to support the parallel execution of a large number of generally synchronized threads, using a common instruction unit configured to issue instructions to a set of processing engines within the GPC 208. Unlike a SIMD execution regime, where all processing engines typically execute identical instructions, SIMT execution allows different threads to more easily follow diverging execution paths through a given program. Those skilled in the art will understand that a SIMD processing regime represents a functional subset of a SIMT processing regime.
[0038] In one embodiment, the operation of the GPC 208 is controlled by a pipeline manager 305, which distributes processing tasks received by a work distribution unit (not shown) within the task / work unit 207 to one or more streaming multiprocessors (SMs) 310. The pipeline manager 305 can also be configured to control a work distribution crossbar 330 by specifying destinations for processed data output by the SMs 310.
[0039] In various embodiments, the GPC 208 comprises a set of M SMs 310, where M ≥ 1. Each SM 310 also comprises a set of functional execution units (not shown), such as execution units and load-store units. Processing operations specific to each of the functional execution units can be arranged in a pipeline, allowing a new instruction to be issued for execution before a previous instruction has completed. Any combination of functional execution units within a given SM 310 can be provided. In various embodiments, the functional execution units can be configured to support a variety of different operations, including integer and floating-point arithmetic (e.g.,Addition and multiplication), comparison operations, Boolean operations (AND, OR, 5OR), bit shifting, and calculation of various algebraic functions (e.g., planar interpolation and trigonometric, exponential, and logarithmic functions, etc.). Advantageously, the same functional execution unit can be configured to perform different operations.
[0040] In one embodiment, each SM 310 is configured to process one or more thread groups. As used herein, a "thread group" or "warp" refers to a group of threads that simultaneously execute the same program on different input data, with one thread of the group being assigned to (or mapped to) a different execution unit within an SM 310. A thread group may contain fewer threads than the number of execution units within the SM 310, in which case some execution may be idle during cycles when that thread group is being processed. A thread group may also contain more threads than the number of execution units within the SM 310, in which case processing may occur over successive clock cycles.Since each SM 310 can support up to G thread groups simultaneously, it follows that up to G*M thread groups can be executed in the GPC 208 at any given time.
[0041] Additionally, in one embodiment, a plurality of related thread groups (at different stages of execution) can be active simultaneously within a single SM 310. This collection of thread groups is referred to herein as a "cooperative thread array" (CTA) or "thread array." The size of a given CTA is equal to m*k, where k is the number of concurrently executing threads in a thread group, which is typically an integer multiple of the number of execution units within the SM 310, and m is the number of concurrently active thread groups within the SM 310. In some embodiments, a single SM 310 can support multiple CTAs simultaneously, with such CTAs having the granularity with which work is distributed among the SMs 310.
[0042] In one embodiment, each SM 310 contains a Level-One (L1) cache or uses space in a corresponding L1 cache outside the SM 310 to support, among other things, load and save operations performed by the execution units. Each SM 310 also has access to Level-Two (L2) caches (not shown) shared by all GPCs 208 in the PPU 202. The L2 caches can be used to transfer data between threads. Finally, the SMs 310 also have access to an off-chip “global” memory, which may include the PP memory 204 and / or the system memory 104. It is understood that any memory outside the PPU 202 can be used as global memory. Additionally, as shown in Fig. Figure 3 shows that a Level One Point Five (L1.5) cache 335 is contained within the GPC 208 and configured to receive and hold data requested from the memory via the memory interface 214 by the SM 310. Such data can, without limitation, include instructions, uniform data, and constant data. In embodiments having multiple SMs 310s within the GPC 208, the SMs 310 can advantageously share common instructions and data cached in the L1.5 cache 335.
[0043] In one embodiment, each GPC 208 can have an associated memory management unit (MMU) 320 configured to map virtual addresses to physical addresses. In various embodiments, the MMU 320 can be located either within the GPC 208 or within the memory interface 214. The MMU 320 includes a set of page table entries (PTEs) used to map a virtual address to a physical address of a tile or memory page, and optionally a cache row index. The MMU 320 can include address translation buffers (TLBs) or caches, which may be located within the SMs 310, within one or more L1 caches, or within the GPC 208.
[0044] In one embodiment, the GPC 208 can be configured in graphics and computing applications such that each SM 310 is coupled with a texture unit 315 to perform texture mapping operations, such as determining texture sample positions, reading texture data and filtering texture data.
[0045] In one embodiment, each SM 310 transfers a processed task to the work-distribution crossbar 330 to make the processed task available to another GPC 208 for further processing or to store the processed task in an L2 cache (not shown), parallel processing memory 204, or system memory 104 via the crossbar unit 210. Additionally, a pre-raster operations (PreROP) unit 325 is configured to receive data from the SM 310, route data to one or more raster operations (ROP) units within the partition units 215, perform color mixing optimizations, organize pixel color data, and perform address translations.
[0046] It is understood that the architecture described herein is for illustrative purposes only and that variations and modifications are possible. Among other things, any number of processing units, such as SMs 310, texture units 315, or PreROP units 325, can be contained within the GPC 208. As mentioned above in conjunction with Fig. As described in section 2, the PPU 202 can further comprise any number of GPCs 208 configured to be functionally similar to one another, so that the execution behavior does not depend on which GPC 208 receives a particular processing task. Furthermore, each GPC 208 operates independently of the other GPCs 208 in the PPU 202 to execute tasks for one or more application programs.
[0047] Fig. Figure 4 is a block diagram illustrating an exemplary cloud computer system according to various embodiments. As shown, a computer system 400 comprises one or more servers 402 communicating with one or more client devices 404 over one or more networks 406. Each of the one or more servers 402 may include similar components, features, and / or functionality to the exemplary computer system 100 described above in conjunction with Fig. 1-3 is described. Each of the one or more Server 402 can comprise any technically feasible type of computer system, including, without limitation, a server machine or server platform. Each of the one or more Client Devices 404 can also comprise similar components, features, and / or functionality to the Computer System 100, except that each Client Device 404 runs a Client Application 422 instead of the Rendering Application 130. Each of the one or more Client Devices 404 can comprise any technically feasible type of computer system, including, without limitation, a desktop machine, a laptop machine, a handheld / mobile device, and / or a portable device.In some embodiments, one or more of the one or more servers 402 and / or the one or more client devices 404 can be replaced by one or more virtualized processing environments, such as one or more virtualized processing environments provided by one or more VMs and / or containers running on one or more underlying hardware systems. The one or more networks 406 can include any type of network(s), such as one or more local area networks (LANs) and / or wide area networks (WANs) (e.g., the Internet).
[0048] In some embodiments, the one or more servers 402 may be contained in a cloud computing system, such as a public cloud, a private cloud, or a hybrid cloud, and / or in a distributed system. In such a case, games stored and executed on the one or more servers 402 are streamed as videos to the one or more client devices 404 via one or more client applications 422 running on them. During game sessions, the one or more client applications 422 process user input and transmit this input to the one or more servers 402 for execution in the game. Although cloud-based gaming platforms are described herein as a reference example, those skilled in the art will recognize that the one or more servers 402 can generally execute any technically feasible type of application(s), such as the design applications described above.
[0049] As shown, each of the one or more client devices 404 comprises one or more input devices 426, the client application 422, a communication interface 420, and a display 424. The one or more input devices 426 can include any type of device(s) for receiving user input, such as a keyboard, mouse, joystick, and / or game controller. The client application 422 receives input data in response to user input at the one or more input devices 426, transmits the input data to one of the one or more servers 402 via the communication interface 420 (e.g., a network interface controller) and via the one or more networks 406 (e.g., the Internet), receives encoded display data from the server 402, decodes it, and causes the display data to be shown on the display 424 (e.g., a screen).(e.g., a cathode ray tube, a liquid crystal display, a light-emitting diode display, or similar device). This allows more computationally intensive calculations and processing to be offloaded to one or more 402 servers. For example, a game session could be streamed from one or more 402 servers to one or more 404 client devices, thereby reducing the graphics processing and rendering demands on those client devices.
[0050] As shown, each of the one or more Servers 402 comprises a communication interface 418, one or more CPUs 408, a parallel processing subsystem 410, a rendering component 412, a rendering capture component 414, and an encoder 416. Input data transmitted by the client device 404 to one of the one or more Servers 402 is received via the communication interface 418 (e.g., a network interface controller) and processed by the one or more CPUs 408 and / or the parallel processing subsystem 410 contained in that Server 402, which, in conjunction with the CPU 102 or the parallel processing subsystem 112 of the above, Fig. The computer system 100 described in sections 1-3 is processed. In some embodiments, one or more CPUs 408 can receive the input data, process the input data, and transfer data to the parallel processing subsystem 410. The parallel processing subsystem 410, in turn, renders one or more independent images and / or frames, such as the frames of a video game, based on the transferred data.
[0051] For illustrative purposes, the rendering component 412 uses the parallel processing subsystem 112 to render the result of processing the input data, and the rendering capture component 414 captures the rendering as display data (e.g., as image data capturing one or more independent images and / or image frames). The rendering performed by the rendering component 412 may include ray- or path-traced lighting and / or shadow effects, which are computed using one or more parallel processing units—such as GPUs, which may further utilize one or more dedicated hardware accelerators or processing cores to perform ray- or path-tracing techniques—of the server 402. In some embodiments, the rendering component 412 performs the rendering using the texture filtering techniques disclosed herein.The encoder 416 then encodes display data captured by the rendering to generate coded display data, which is transmitted via the one or more networks 406 through the communication interface 418 to the one or more client devices 404 for display to one or more users. In some embodiments, the rendering component 412, the rendering capture component 414, and the encoder 416 may be included in the rendering application 130, which is described above in conjunction with... Fig. 1 is described.
[0052] Returning to the cloud gaming example, during a game session, input data received from one or more servers (402) can be representative of a user character's movement in a game, firing a weapon, reloading, passing a ball, turning a vehicle, and so on. In such a case, the rendering component (412) can produce a rendering of the game session that is representative of the outcome of the input data, and the rendering capture component (414) can capture the game session's rendering as display data (e.g., image data capturing rendered frames of the game session). Parallel processing resources (e.g., GPU) can be dedicated to each game session, or resource scheduling techniques can be used to share parallel processing resources across multiple game sessions.Additionally, the game session can be rendered using the texture filtering techniques disclosed herein. The rendered game session can then be encoded by the encoder 416 to produce encoded display data, which is transmitted via the one or more networks 406 to one or more client devices 404 for decoding and output via the display 424 of that client device 404.
[0053] It is understood that the architecture described herein is for illustrative purposes only and that variations and modifications are possible. Among other things, any number of processing units, such as the SMs 310, texture units 315, or PreROP units 325, which are mentioned above in conjunction with... Fig. 3 are described within GPC 208. Stochastic texture filtering through Single Instruction Multiple Threads and Single Instruction Multiple Data Lane communication
[0054] Fig. Figure 5 illustrates how texture filtering can be performed using deterministic square footprints and pseudorandom sparse footprints for texel sharing within a Wave, according to various embodiments. As shown, sets of footprints 500 and 510 indicate how texel samples can be shared between lanes in a Wave running on a processor, such as a GPU. Although described here primarily with respect to GPUs as a reference example, the techniques disclosed herein can be implemented in some embodiments using any suitable processor. For illustrative purposes, sets of footprints 500 and 510 include footprint 502. i (hereinafter collectively referred to as Footprints 502 and individually as a Footprint 502) or Footprints 512 i(hereinafter collectively referred to as Footprints 512 and individually as a Footprint 512) for different lanes in a wave. Histograms 508 and 518 show the frequency of texel sample reuse per wave lane for each set of Footprints 500 and 510, respectively.
[0055] For illustrative purposes, the sets of footprints 500 and 510 are associated with a wave of size 32, configured as 8×4 lanes. Each lane in a GPU is an execution thread. A set of lanes executing concurrently in parallel together forms a wave (also called a "warp"), which is a basic unit of execution for GPU operations. For example, in some implementations, the lanes of a wave can be accessed via the SMs 310 of a GPC 208, which are described above in conjunction with Fig. 2- Fig. The processes described in Section 3 are executed as follows. The 32 illustrated lanes in a Wave can each be configured to process a different pixel in parallel, so that together the 32 Waves process a grid of, for example, 16×2 or 8×4 pixels in parallel. In some embodiments, in addition to performing processing for a pixel, each lane can obtain texel values from other lanes in the Wave based on a predetermined sharing footprint, such as one of Footprints 502 or 512. The footprints can be either deterministic, for example, 2×2 or 3×3 squares as in the set of Footprints 500, or pseudorandom, sparse footprints as in the set of Footprints 510.In some implementation examples, footprints can be designed according to the following criteria: (1) favoring lanes close to the current lane to improve the chances of sharing a useful texel value, (2) using the same sharing filter footprint size for all lanes within a wave to avoid unnecessary thread divergence, and (3) maximizing the variety of shared texel values between lanes.
[0056] Although the illustrated footprints are for a Wave configuration of size 32, in some embodiments the disclosed techniques can be generally applied to Wave sizes of 8, 16, 64, or any other arrangement supported by a GPU. Although described with respect to the use of Wave intrinsics for sharing texel samples among the lanes of a Wave, in some embodiments quad intrinsics can be used when the GPU only provides subgroup operations over 2×2 quads, although Wave intrinsics typically provide more flexibility for sharing texel samples across a larger set of lanes. Although described with respect to specific footprints 502 and 512 as reference examples, in some embodiments any suitable footprints can be used.Larger footprints, for example 3×3 or 4×4, generally allow for more thorough sharing of contributing texels, but can increase shading time overhead. In some implementations, any suitable footprint size and pattern can be selected to balance performance and filter quality requirements.
[0057] As shown, each lane in a wave, such as lane 504 or 514, captures a single texel sample and also receives one or more texel samples from a set of contributing lanes, such as lanes 506. i (hereinafter collectively referred to as Lanes 506 and individually as Lane 506) for Lane 504 and Lanes 516 i(hereinafter collectively referred to as Lanes 516 and individually as a Lane 516) for Lane 514. In some embodiments, the texel samples can be transferred via (through, or using) Wave intrinsics, which allow adjacent or nearby Lanes to read coordinates and / or texel values without incurring additional memory bandwidth costs. The combined set of texel samples contributing to each Lane is referred to herein as a Footprint.
[0058] In some implementations, the GPU can store multiple candidate footprints for each pixel in a wave and randomly select from these candidate footprints for each frame or shading pass. In such cases, instead of assigning exactly one deterministically configured footprint (e.g., a 3×3 square or pseudorandom footprint) to each lane, the GPU can store a set of footprints valid for the pixel or lane. For each pixel, a footprint can be randomly selected from this set for use.
[0059] Two exemplary approaches to defining footprints are presented in Fig. Figure 5 shows that for deterministic square footprints 502, each target lane (e.g., lane 504 or 514) has 8 spatially adjacent contributing lanes to form a 3×3 square footprint spanning a wave. For example, lane 504 has 8 spatially adjacent contributing lanes 506. Deterministic square footprints provide localized texel reuse, so nearby lanes often sample the same regions in a texture. For pseudorandom footprints 512, each target lane has 8 contributing lanes that are irregularly placed (arranged) around the target lane. For example, lane 514 has 8 contributing lanes 516 that are irregularly placed around lane 514. The sparse pseudorandom footprints can distribute Texel samples more randomly among lanes in a wave, thereby improving denoising performance for image regions under magnification.
[0060] Histograms 508 and 518 show how often a texel sample from a given wave lane (index from 0 to 31) is used for all pixels in the wave for the set of square footprints 500 and the set of pseudorandom footprints 510, respectively. To illustrate, the reuse frequency for each wave lane can be more uniform with pseudorandom footprints 512, which can prevent overuse of certain lanes. With deterministic footprints, such as footprints 502 in the set of square footprints 500, corner or edge lanes tend to be selected less frequently, resulting in greater variance in sample reuse. In contrast, pseudorandom footprints such as the footprints 512 in the set of footprints 510 can balance the number of contributions from each lane to the target lane (e.g., the contributions of other lanes 516 to lane 514), thereby reducing potential artifacts and improving the overall image quality.
[0061] In some implementations, once a lane has sampled its own texel, it captures the sampled coordinates, the probability distribution function (PDF) value, and texel values from other lanes specified by the sharing footprint associated with the lane, using Wave intrinsics. The PDF value captured from other lanes indicates the probability of selecting a particular texel from the texture, so the average of random selections converges to the true selected filtered value. In some implementations, the lane can access values from other lanes in the sharing footprint by making WaveReadLaneAt(value, laneld) function calls. Wave intrinsics have relatively low overhead because they are typically implemented as swap or shuffle instructions within a Wave, thus costing only one instruction with no impact on memory bandwidth.Furthermore, texture filter quality can be improved by sharing samples between pixels in a footprint.
[0062] In stochastic texture filtering, each pixel randomly selects a texel based on a PDF that reflects the contribution weights. For example, if a bilinear filter is stochastically approximated, the probability of selecting one of the four nearest texels is proportional to the interpolation weight of texture coordinates (u, v).
[0063] After lane i receives a texel sample, the lane also calls integer coordinates (u i , v i ) from Texel x i , PDF values and Texel values f(x i ) from other lanes in the footprint for the lane. The integer Texel coordinates (u i , v i These values are needed to calculate the filter sampling PDF for the current lane. i (x i) demonstrates the PDF value with which lane i within a filter footprint Texel sample x i sampled, and p c (x i ) is the PDF value that passes through the lane Texel x i is assigned.
[0064] In some embodiments, determining a texel value for a lane involves calculating, through the lane, a set of weights w i , which with respective Texels x i are associated. Each weight w i gives the contribution of the corresponding Texel x i to the final texel value of the lane according to the Weighted Importance Sampling (WIS) estimator of Equation 1. ∑inf(xi)pi(xi) / ∑inpc(xi)pi(xi) where p i the probability of sampling each x i is when an x i from each of n PDFs p i is drawn, and p cThe PDF is used to sample the filter at the current pixel. In operation, a lane can calculate a weight to be applied to each texel sample read by another lane in the footprint associated with that lane, according to the WIS estimator of Equation 1; add the texel samples read by other lanes, weighted by the corresponding weights, to obtain an intermediate result; add the weights to obtain an accumulation of weights; and divide the intermediate result by the accumulation of weights to compute a filtered value. The computed filtered value is a statistical estimate of a stochastically filtered texture that approximates the value of fully deterministic texture filtering by hardware. In some embodiments, each lane can perform the operations of Algorithm 1 to compute the filtered value.The weighted approach described above limits each output color to the convex hull of all contributed texels, thus preventing a filtered result from exceeding the minimum or maximum texel value among samples.
[0065] In Algorithm 1, the texel sharing footprint is encoded as a lookup table in the waveLaneSet array. If deterministic sharing footprints are used, the corresponding offsets can be calculated at runtime. The number of loop iterations (FOOTPRINT_SIZE) is based on the size of the sharing footprints.
[0066] In Algorithm 1, the code `uint laneldx = waveLaneSet [currentLaneldx][idx]` is used to retrieve the ID of a lane in a footprint stored in a lookup table. In some implementations, a lane can perform bit manipulations and arithmetic to calculate the ID of each lane in the footprint, which is less computationally intensive than using a lookup table. For example, for 3x3 square footprints, Algorithm 2 could be used to calculate the ID of each lane in the footprint.
[0067] In some implementations, to determine the ID of the lane in the footprint, a more efficient lookup can be performed where a 32-bit value uses each bit to indicate whether the corresponding lane should be included or not. For example, in such cases, Algorithm 3 could be used to calculate the ID of each lane in the footprint.
[0068] Accordingly, some implementations implement a WIS estimator to calculate the final filtered texture value, which can be written as shown in Equation 2. Equation 2 states that if the lane has n samples (u i , v i ) from various PDFs p i Aggregated, the estimate for the filtered texture value can be expressed as ∑infc(ui,vi)Tui,vi / pi(ui,vi)∑inpc(ui,vi) / pi(ui,vi), where f c (u i , v i ) the texture reconstruction filter of the current lane is and T ui,vi a set of texels at integer coordinates (u i , v i ) represents values scaled by translated Dirac delta functions to calculate a texture value. If the texture reconstruction filter is positive and normalized, then p can c (u i , v i ) = f c (u i , v i ) and similarly p i = fi Equation 2 can be written as ∑infc(ui,vi)Tui,vi / fi(ui,vi)∑infc(ui,vi) / fi(ui,vi).
[0069] If the weights w i as wi=fc(ui,vi)fi(ui,vi) are defined, equation 3 becomes ∑inwi∑jnwjTui,vi.
[0070] Thus, the weights are normalized and sum to one, ensuring that the estimator generates a convex combination of the filtered texels. As a result, constant texture regions exhibit no error.
[0071] In some implementations, if the contributed texels include all the texels required for a small filter footprint (e.g., a 2×2 bilinear filter), the rendering process can perform exact filtering by deterministically mixing texels. Exact filtering bypasses the stochastic estimator and produces a filter result consistent with a conventional bilinear technique. In some implementations, the detection of an entire set of required texels for a small footprint triggers a switch to exact filtering. In such cases, a lane identifies the presence of all unique texels (e.g., four unique texels) necessary for filtering and computes a fully mixed output, thus eliminating the dependence on an estimator.Exact filtering can be used at high magnification, where overlapping footprints can result in matching texels. Accordingly, the GPU can employ a hybrid strategy, using exact filtering when the contributed texels cover every required sample, and weighted sampling elsewhere.
[0072] Fig. Figure 6 illustrates two exemplary techniques for defining 2×2 footprints in a wave of size 16, arranged as a 4×4 grid of lanes, according to different embodiments. As shown, sets of footprints 600 and 610 include footprints 602. i (hereinafter collectively referred to as Footprints 602 and individually as a Footprint 602) or 612 i(hereinafter collectively referred to as Footprints 612 and individually as a Footprint 612). Each Footprint specifies a target lane and a set of contributing lanes that provide texel samples for the target lane for the purpose of calculating a filtered color. For example, target lane 604 in Footprint 602 reads texel samples from contributing lanes 606. i (hereinafter collectively referred to as Contributing Lanes 606 and individually as Contributing Lane 606), and the target lane 614 in Footprint 612 reads Texel samples from Contributing Lanes 616 i (hereinafter collectively referred to as Contributing Lanes 616 and individually as a Contributing Lane 616).
[0073] To illustrate, a wave associated with footprint 602 in the set of footprints 600 can contain 16 lanes configured to process different pixels in parallel within a 4×4 grid of pixels. Quad intrinsics allow texel samples to be shared among groups of four lanes (e.g., 2×2 quads) starting at even (x, y) coordinates, meaning that each target lane (e.g., lane 604) in a quad is on the same 2×2 footprint of contributing lanes (e.g., lanes 606). i (for the target lane 604). At high magnification, 2×2 regions produce nearly identical color after stochastic filtering, as illustrated by diagram 608. The repeating nature of quad-based footprints means that the same four texels are reused by all lanes within a quad, which can produce larger patches of identical color.
[0074] In some implementations, a spatiotemporal blue noise mask can be used to improve the sampling distribution on each lane. The spatiotemporal blue noise mask introduces randomness, which minimizes the clumping of selected texels and reduces correlated noise between neighboring pixels or across successive frames. In some implementations, scalar blue noise masks can be adjusted to emphasize diagonal neighbors in each lane, reducing the tendency for horizontal or vertical banding. In some implementations, the void and cluster energy splatter function can be configured to apply twice as much energy to the neighbors in each fixed 2×2 quad.
[0075] A wave associated with footprints 612 can also include 16 lanes configured to process different pixels in parallel within a 4×4 grid of pixels, but wave intrinsics are used for footprints 612 within the set of footprints 610. In such cases, a destination lane (e.g., lane 614) can contribute lanes (e.g., lanes 616). i (for target lane 614) select anywhere within the 16-lane configuration, instead of being restricted to hardware-defined quads. This flexibility allows the 2×2 footprints to extend beyond quad boundaries and minimize large uniform color areas. The example in Diagram 618 shows a scattered distribution of samples, which generally improves image quality under magnification by avoiding blocky artifacts.
[0076] Similar to the above description in conjunction with Fig. 5. Both the Footprints 600 set and the Footprints 610 set can be used to replace texel data with intrinsics instead of requiring additional memory fetches, and filtered color values can be obtained using the replaced texel data as described above in conjunction with Fig. The five described techniques are used for calculation. In the quad-based arrangement of the set of Footprints 600, uniform regions are more pronounced, while the wave-based arrangement of the set of Footprints 610 allows for broader randomness and reduced repeating color. Consequently, Footprints defined by wave intrinsics can provide finer control over sharing patterns and mitigate artifacts associated with enhanced texture filtering.
[0077] Fig. Figure 7 illustrates exemplary texture filtering results produced using various techniques, according to different embodiments. As shown, example image 702 includes an image region 704 for which various filtering techniques were applied to produce images 706-724, which allow a visual comparison of the different filtering techniques and the improvements achieved by the disclosed techniques.
[0078] The generated images 706-724 are shown as two sets of five images each, comparing filtering results under different techniques. Each set includes a ground-truth image (706 for the bilinear case and 716 for the bicubic case), a base stochastic texture filtering (STF) result (708 and 718, respectively), a denoised STF result (710 and 720, respectively), a result obtained using the filtering techniques and pseudorandom footprints disclosed herein (712 and 722, respectively), and a denoised result using the filtering techniques and pseudorandom footprints disclosed herein (714 and 724, respectively). The ground-truth images 706 and 716 provide a reference showing the texture without artifacts, noise, or approximation errors. The remaining images 708, 710, 712, 714, 718, 720, 722 and 724 can be compared with the basic truth images 706 and 716.
[0079] The top row of images 706, 708, 710, 712, and 714 demonstrates the effect of various filtering techniques using bilinear texture filtering. STF image 708 shows perceptible noise and low-resolution interpolation, a characteristic result of standard stochastic single-sample filtering, where each pixel randomly selects a texel based on PDFs. The filtering errors in STF image 708 are particularly pronounced in high-magnification regions, where texel selection randomness can lead to structured noise patterns.
[0080] The denoised STF image 710 is generated by applying a spatiotemporal denoising filter to STF image 708, which reduces noise resulting from texel reuse within a fixed deterministic footprint. While the denoiser reduces noise, blocky (block-like) patterns formed by correlated texel sampling remain unresolved. Image 712 was generated using the filtering techniques disclosed herein. In particular, pseudorandom footprints, as described above in conjunction with Fig. The method described in Section 5 is used to generate image 712, resulting in a more uniform texel distribution and reduced structured noise. Compared to STF image 708, image 712 includes fewer correlated patterns, improving texture reconstruction without introducing excessive noise. A denoised version of image 712, namely image 714, further refines image 712, resulting in a visually smoother image. In particular, the use of pseudorandom footprints prevents the overrepresentation of specific texels, making the denoising process more effective compared to the denoised STF image 710, where deterministic footprints cause artifacts that are more difficult to remove.
[0081] The bottom row of images 716, 718, 720, 722, and 724 was generated using the same filtering techniques with bicubic B-spline filtering. The baseline image 716 serves as a reference for the bicubic filtering results. The STF image 718 demonstrates loss of detail due to the stochastic sampling approach. The denoised STF image 720 improves on image 718, reducing noise, but still suffers from artifacts compared to the baseline image 716. The deterministic footprint selection in STF leads to clusters of similar texel values, preventing complete detail recovery in the bicubic filter.
[0082] Image 722, generated using the techniques disclosed herein, features improved texture detail preservation compared to STF image 718. By employing pseudorandom footprints, the disclosed filtering techniques reduce texel clustering and provide a more uniform sample selection, thus enhancing the effectiveness of bicubic B-spline filtering. The denoised result of image 722, namely image 724, provides a high-quality reconstruction of image 722.
[0083] For illustrative purposes, images 712, 714, 722 and 724, produced using techniques disclosed herein, show improvements including a reduction of structured artifacts, improved denoising results and high-quality texture reconstruction compared to images 708, 710, 718 and 720, produced using conventional approaches.
[0084] Fig. Figure 8 is a more detailed illustration of the Footprint Generator 128 by Fig. 1, according to various embodiments. As shown, the footprint generator 128 comprises, without limitation, a footprint generation module 802 and an iterative optimization module 804. The iterative optimization module 804 comprises, without limitation, an evaluation module 806. The footprint generator 128 is configured to generate one or more sets of pseudorandom footprints, such as the set of pseudorandom footprints 510 described above in conjunction with Fig. 5 is described, for use in texture filtering according to the techniques disclosed herein.
[0085] In operation, the Footprint Generator Module 802 generates a set of pseudorandom footprints for each pixel in a set of pixels. In some embodiments, the Footprint Generator Module 802 can sample neighboring pixels so that they are included in each footprint, for example, using a Gaussian distribution. The set of pixels can correspond to pixels processed by different lanes in a Wave. Each footprint defines a pattern of contributing texels from surrounding pixels, thus enabling texel sampling across lanes within a Wave, as described above in conjunction with Fig. 5 described.
[0086] After generating sets of pseudorandom footprints for each pixel, the iterative optimization module 804 performs iterative optimization to generate a set of footprints as follows. For each pixel within the set of pixels, the iterative optimization module 804 randomly selects one footprint from the set of footprints generated for that pixel. Together, the randomly selected footprints for the pixels form a set of footprints for the set of pixels. The iterative optimization module 804 computes a score for the set of footprints based on a histogram analysis of the number of times each pixel appears in the set of footprints. A histogram provides a statistical evaluation of texel reuse uniformity, similar to the analysis provided by histogram 518 of Fig. Figure 5 illustrates this. The histogram is used to prevent disproportionate pixel sampling, which could otherwise introduce noise artifacts. In some embodiments, the evaluation module 806 calculates the score for the selected set of footprints using a score function that evaluates footprint coverage over the wave. For example, in some embodiments, the evaluation module 806 can calculate the score as the standard deviation of the histogram. In such cases, a higher score corresponds to a more uniform distribution of texel samples, which reduces overrepresentation of specific texels that can contribute to noise artifacts and filtering inaccuracies. The iterative optimization module 804 then determines whether the calculated score is better (e.g., higher or lower, depending on the score being calculated) than the best (e.g.,The highest or lowest previously recorded rating for a set of footprints is used. Returning to the example where the rating is calculated as a standard deviation, the iterative optimization module 804 could determine whether the standard deviation of the histogram is higher than a highest standard deviation calculated for histograms associated with previously considered sets of footprints. If the calculated rating is better than the best previous rating, then the iterative optimization module 804 stores the set of footprints as a set of footprints associated with the best rating, shown as a best set of footprints 808. Storing the best set of footprints 808 facilitates convergence to an optimized footprint selection that maximizes texel reuse efficiency while reducing sampling correlations.The preceding steps can be repeated any number of times, such as for a fixed number of iterations (e.g., 1000 iterations), after which the footprint generator 128 can output the stored best set of footprints as a set of footprints 810 for use in texture filtering according to the techniques disclosed herein. For example, in some embodiments, the set of footprints 810 can be used within the parallel processing subsystem 112 of . Fig. 1 and associated GPCs 208 and PPUs 202 are implemented, illustrated in Fig. 2 and Fig. 3. Additionally, in some embodiments, the footprint generator 128 can generate more than one set of footprints. In such cases, the parallel processing subsystem 112 can switch between different sets of footprints during image rendering.
[0087] Fig. Figure 9 is a flowchart of process steps for generating and optimizing pseudorandom footprints for texel sharing within a wave, according to various embodiments. In some embodiments, the process steps can be performed on a computer system, such as the one described above in conjunction with Fig. 1 described computer system 100, which includes the parallel processing subsystem 112 capable of performing texture filtering operations. Although the process steps in conjunction with the systems of Fig. 1- Fig. As described in Section 8, the person skilled in the art will understand that any system configured to perform the process steps in any order falls within the scope of this disclosure.
[0088] As shown, a procedure 900 begins at step 902, where the footprint generator 128 generates a set of pseudorandom footprints for each pixel in a set of pixels. The set of pixels can correspond to pixels processed by different lanes in a wave. Each footprint defines a pattern of contributing texels from surrounding pixels, thus enabling texel sampling across lanes within a wave, as described above in conjunction with Fig. 5 described. In some embodiments, the footprint generator can sample 128 neighboring pixels so that they are included in every footprint, for example, using a Gaussian distribution. The pseudorandom footprints are designed to provide sample distribution variability across different rendering frames, thereby reducing noise, as described in Fig. Figure 7 illustrates this. Footprints can be found within the parallel processing subsystem 112 in Fig. 1 are used, with parallel processing units (PPUs) such as 202 in Fig. 2 can be used to perform filtering across different wave sizes, including 8, 16, 32, and 64 lanes, providing compatibility with various GPU architectures, as described above in conjunction with Fig. 5 and Fig. 6 described.
[0089] In step 904, the footprint generator 128 randomly selects a footprint from the set of footprints generated for each pixel within the set of pixels. The selected footprints are implemented in a way that distributes texel contributions, such as the contributing lanes 516, which were mentioned above in conjunction with Fig. 5 are described. The randomized selection of footprints can help to mitigate the overrepresentation of specific texels, thereby improving the effectiveness of filtering operations.
[0090] In step 906, Footprint Generator 128 calculates a score for the selected set of footprints based on a histogram analysis of the number of times each pixel appears in the selected footprints. The histogram provides a statistical assessment of texel reuse uniformity, similar to the analysis provided by histogram 518 of Fig. Figure 5 illustrates this. The histogram is used to prevent disproportionate pixel sampling, which could otherwise introduce noise artifacts. In some embodiments, the Footprint Generator 128 calculates the score for the selected set of footprints using a scoring function that evaluates the footprint coverage over the waveform. For example, in some embodiments, the score can be calculated as the standard deviation of the histogram. In such cases, a higher score corresponds to a more uniform distribution of texel samples, which reduces overrepresentation of specific texels that can contribute to noise artifacts and filtering inaccuracies.
[0091] In step 908, Footprint Generator 128 determines whether the calculated score is better (e.g., higher or lower, depending on the score being calculated) than the best (e.g., highest or lowest) previously recorded score. Returning to the example where the score is calculated as a standard deviation, Footprint Generator 128 might determine whether the histogram's standard deviation is higher than a highest standard deviation calculated for histograms associated with previously considered sets of footprints. If the calculated score is not better than the best previous score (908 - No), then Procedure 900 proceeds to Decision Step 912, where a determination is made as to whether the optimization process should continue.If the calculated score is better than the best previous score (908 - Yes), then procedure 900 proceeds to step 910, where the current set of footprints is stored as the set associated with the best score. Storing the best-scored footprint set facilitates convergence to an optimized footprint selection that maximizes texel reuse efficiency while reducing sampling correlations.
[0092] At step 912, the footprint generator 128 determines whether the optimization process should continue. For example, in some embodiments, the optimization process can be performed for a predefined number of iterations. If the process is to continue (912 - Yes), then the procedure returns to step 902, where the footprint generator 128 generates a new set of pseudorandom footprints. This iterative approach allows for the refinement of the footprint selection through successive iterations, facilitating convergence to an optimized set of footprints. If the optimization process is to terminate (912 - No), then the procedure ends at step 900, finalizing the highest-rated set of footprints for use in texel-sharing operations during rendering. For example, in some embodiments, the finalized footprint set can be used within the parallel processing subsystem 112 of Fig. 1 and associated GPCs 208 and PPUs 202 are implemented, illustrated in Fig. 2 and Fig. 3. In addition, in some embodiments, more than one set of footprints can be generated according to method 900, and the parallel processing subsystem 112 can switch between different sets of footprints during the rendering of images.
[0093] Fig. Figure 10 is a flowchart of process steps for performing rendering with texel sharing between lanes, according to various embodiments. In some embodiments, the process steps can be executed on a parallel processing subsystem, such as the one described above in conjunction with Fig. 1- Fig. 3 described parallel processing subsystem 112. Although the process steps in conjunction with the systems of Fig. 1- Fig. As described in Section 8, the person skilled in the art will understand that any system configured to perform the process steps in any order falls within the scope of this disclosure.
[0094] As shown, a procedure 1000 begins at step 1002, with each lane in a wave (e.g., on SMs 310 of one of the GPCs 208 of the PPU 202, which are linked above) Fig. 2- Fig. (as described in section 3, which can be executed) samples a texel based on a filter type and a sample PDF. The filter type can include bilinear filtering or bicubic B-spline filtering, as described in Fig. Figure 7, or any other technically feasible texture filtering technique. The sample PDF determines the probability of selecting a particular texel from the texture, ensuring that the selection follows the weighting rules of the applied filter. In some embodiments, the lane can sample integer coordinates (which may involve retrieving a value from memory) and (1) use the sampled coordinates to compute the PDF that specifies the filter value for the texel, and (2) obtain a texture value using the sampled coordinates, as shown above in Algorithm 1.
[0095] In step 1004, each lane uses Wave (or Quad) intrinsics to retrieve texel samples, integer texel coordinates, and PDF values from other lanes within the Wave, based on a corresponding sharing footprint (e.g., footprint 502 or 512, which is defined in Fig. 5 is shown, or 602 or 612, which is in Fig. 6 is shown); calculates weights for the texel samples; and computes a normalized accumulation (summing) of weighted texels. The footprints define the set of contributing lanes, such as lane 516, which is shown in Fig. Figure 5 shows the Texel values for each target lane, such as target lane 514 in Fig. 5. The footprints can be from a set of square footprints or a set of pseudorandom footprints, generated, for example, according to method 900 of Fig. 9. In some embodiments, when more than one set of footprints is generated according to Method 900, a GPU can switch between different sets of footprints while rendering images. In some embodiments, the ID of each lane in a footprint can be stored in a lookup table. In some embodiments, a lane can perform bit manipulation and arithmetic to calculate the ID of each lane in the footprint, which is less computationally intensive than a lookup table. In some embodiments, to determine the ID of the lane in the footprint, a lane can perform a more efficient lookup where a 32-bit value uses each bit to indicate whether the corresponding lane should be included or not.
[0096] Once the Texel samples from other lanes, the integer Texel coordinates, and the PDF values are obtained by each target lane, the target lanes each calculate a set of weights (w i) for each texel sample according to the WIS estimator of Equation 1. After calculating the weights, each target lane computes a normalized accumulation of weighted texels that includes the texel samples retrieved by other lanes in the footprint, weighted by the corresponding weights, as shown in Algorithm 1. The normalized accumulation of weighted texels is a statistical estimate of a stochastically filtered texture that approximates the value of fully deterministic texture filtering by hardware. The weighted accumulation process ensures that a final computed filtered texel for each lane remains within the convex hull of all texel samples, preventing a result from exceeding the minimum or maximum texel values among samples, thereby reducing noise artifacts.Although described in terms of computing a normalized accumulation of weighted texels, in some embodiments, where contributed texels include all texels required for a small filter footprint (e.g., a bilinear 2×2 filter), the rendering process can perform exact filtering by mixing texels in a deterministic way, bypassing the stochastic estimator and producing a filter result consistent with a conventional bilinear technique, as described above in conjunction with . Fig. 5 described.
[0097] In step 1006, the parallel processing subsystem 112 renders at least one section of an image based on the normalized accumulation of weighted texels. The final calculated filtered texels from step 1004 are used for texture reconstruction during the rendering of an image, such as a standalone image or a frame within a video. The rendering can be performed for any technically feasible application, such as the rendering application 130 described above in conjunction with Fig.1 is described. Rendering may include other operations, such as lighting calculations, shading calculations, and / or noise reduction, which in some embodiments can be performed according to known techniques. For example, during ray-traced rendering, a traced ray might intersect the geometry of a textured object, and techniques disclosed herein can be used to compute filtered texture values based on the intersection point as part of the rendering process.
[0098] In summary, techniques for improving texture filtering by using stochastic sampling in conjunction with inter-threaded communication in GPUs are revealed. In some implementations, a rendering application stochastically samples an initial texel using a filter footprint that spans multiple threads or processing lanes, which may be implemented in software and / or hardware. The filter footprint, which may be square or pseudorandom in design, represents the spatial arrangement used to sample texels for filtering. A square footprint applies uniform sampling over a defined texture surface, while a pseudorandom footprint introduces controlled random sampling to minimize regular sampling patterns that can lead to artifacts.The rendering application uses the filter footprint to access additional texels from neighboring threads via inter-thread communication enabled by the SIMT and / or SIMD architectures in a GPU. The application then assigns a weight to each texel sample, calculated using a PDF that shows the probability of sampling that texel based on the filter footprint. The application normalizes these weights and applies them to each texel to calculate a weighted average, which can then be used to determine a pixel color.
[0099] At least one technical advantage of the disclosed techniques compared to the prior art is that they reduce visual artifacts and noise typically associated with stochastic texture filtering compared to conventional filtering approaches, particularly under magnification conditions or when nonlinear shading, such as normal imaging or specular highlights, is present. By facilitating the efficient sharing and reuse of texture samples across neighboring pixels, the disclosed techniques can be used to generate images that are relatively close in appearance to images produced using hardware filters.Furthermore, the disclosed techniques can achieve rendering improvements while maintaining relatively low computational overhead, including no additional texture look-up costs compared to conventional STF. These technical advantages represent one or more technological improvements over state-of-the-art approaches. 1. In some embodiments, a computer-implemented method for rendering graphic images for each lane contained in a plurality of lanes in a wave comprises sampling a texel based on a filter to generate a texel sample for each lane contained in the plurality of lanes, computing a filtered value based on a plurality of the texel samples read from a corresponding plurality of lanes, based on a footprint associated with the lane, and rendering at least one section of a graphic image based on the filtered values computed for the plurality of lanes. 2. Computer-implemented method according to paragraph 1, wherein the calculation of the filtered value for each lane contained in the corresponding plurality of lanes comprises: reading one or more coordinates, a sampled probability distribution function (PDF) value, and a first texel sample associated with the lane; calculating a weight based on the one or more coordinates and the sampled PDF value; adding the first texel sample, weighted by the weight, to an intermediate result; adding the weight to an accumulation of weights; and dividing the intermediate result by the accumulation of weights to calculate the filtered value. 3. Computer-implemented method according to numbers 1 or 2, wherein the plurality of texel samples is read from the corresponding plurality of lanes via (i.e. by / using) wave intrinsics. 4. Computer-implemented method according to one of the numbers 1-3, wherein the plurality of texel samples is read from the corresponding plurality of lanes via quad intrinsics. 5. Computer-implemented method according to any one of numbers 1-4, wherein the footprint associated with the lane includes at least one of a square footprint, a quad footprint or a pseudorandom footprint. 6. Computer-implemented method according to one of the digits 1-5, wherein the plurality of corresponding lanes is determined based on either a lookup table, one or more bit manipulations and arithmetic, or a value containing a plurality of bits that specify the plurality of corresponding lanes. 7. Computer-implemented method according to any of the numbers 1-6, further comprising performing one or more iterative operations to generate a set of footprints that includes the footprint associated with the lane, based on a histogram of the number of pixels contained in the set of footprints. 8. Computer-implemented method according to any one of the numbers 1-7, wherein calculating a filtered value for each lane comprises calculating a first filtered value for a first lane contained in the plurality of lanes by reading a first plurality of texel samples from a first plurality of lanes based on a first footprint associated with the first lane, and in response to a determination that the first plurality of texel samples can be used in an exact filtering technique, performing the exact filtering technique to compute the first filtered value based on the first plurality of texel samples. 9. Computer-implemented method according to any one of paragraphs 1-8, wherein the rendering of at least one section of the graphic image includes performing at least one of one or more lighting operations or one or more shading operations. 10. Computer-implemented method according to one of the numbers 1-9, wherein the wave is executed via a graphics processing unit (GPU). 11. In some embodiments, one or more non-transitory computer-readable media store instructions which, when executed by at least one processor, cause the at least one processor to perform the following steps: for each lane contained in a plurality of lanes in a wave, sample a texel based on a filter to generate a texel sample; for each lane contained in the plurality of lanes, compute a filtered value based on a plurality of the texel samples read from a corresponding plurality of lanes, based on a footprint associated with the lane; and render at least one section of a graphic image based on the filtered values computed for the plurality of lanes. 12. One or more non-transitory computer-readable media as described in paragraph 11, wherein the calculation of the filtered value for each lane contained in the corresponding plurality of lanes comprises: reading one or more coordinates, a sampled probability distribution function (PDF) value, and a first texel sample associated with the lane; calculating a weight based on the one or more coordinates and the sampled PDF value; adding the first texel sample, weighted by the weight, to an intermediate result; adding the weight to an accumulation of weights; and dividing the intermediate result by the accumulation of weights to calculate the filtered value. 13. One or more non-transitory computer-readable media according to paragraphs 11 or 12, wherein the plurality of texel samples is read from the corresponding plurality of lanes via at least one of wave intrinsics or quad intrinsics. 14. One or more non-transitory computer-readable media according to any of numbers 11-13, wherein the footprint associated with the lane includes at least one of a square footprint, a pseudorandom footprint or a quad footprint. 15. One or more non-transitory computer-readable media according to any of the numbers 11-14, wherein calculating the filtered value includes performing an interpolation to mix the multitude of texel samples. 16. One or more non-transitory computer-readable media according to one of the numbers 11-15, wherein the plurality of lanes corresponds to a plurality of adjacent pixels. 17. One or more non-transitory computer-readable media according to any of the items 11-16, wherein the rendering of the at least one section of the graphic image includes performing one or more denoising operations on the at least one section of the graphic image. 18. One or more non-transitory computer-readable media according to any of the numbers 11-17, wherein the filter comprises either a bilinear filter or a bicubic filter. 19. One or more non-transitory computer-readable media according to any of the items 11-18, wherein at least one processor includes a graphics processing unit (GPU). 20. In some embodiments, a system comprises one or more memories that store instructions, and one or more processors coupled to the one or more memories which, when executing the instructions, are configured to: for each lane contained in a plurality of lanes in a wave, sample a texel based on a filter to generate a texel sample; for each lane contained in the plurality of lanes, compute a filtered value based on a plurality of the texel samples read from a corresponding plurality of lanes, based on a footprint associated with the lane; and render at least one section of a graphical frame based on the filtered values computed for the plurality of lanes. 1. In some embodiments, a computer-implemented method for configuring a processor includes generating a set of footprints based on a histogram of the number with which each pixel from a set of pixels is included in the set of footprints, wherein each footprint included in the set of footprints represents a plurality of pixels around a target pixel for reading texel samples, and configuring the processor to perform texture filtering using the set of footprints when one or more graphic images are rendered. 2. Computer-implemented method according to paragraph 1, wherein generating the set of footprints comprises generating, for each pixel contained in the set of pixels, a corresponding set of footprints, selecting a footprint from the corresponding set of footprints, wherein the set of footprints includes the footprints to be selected, calculating a score based on the histogram, and determining that the score is a highest or a lowest score among one or more scores calculated for one or more sets of footprints. 3. Computer-implemented method according to paragraphs 1 or 2, wherein the evaluation is calculated based on a standard deviation of the histogram. 4. Computer-implemented method according to one of the numbers 1-3, wherein the plurality of pixels around the target pixel includes a pseudo-random selection of pixels from the set of pixels. 5. Computer-implemented method according to one of the numbers 1-4, wherein configuring the processor includes storing the set of footprints in one or more lookup tables on the processor. 6. Computer-implemented method according to one of the digits 1-5, wherein the processor is configured to compute one or more pixels contained in each footprint included in the set of footprints using one or more bit manipulations and arithmetic. 7. Computer-implemented method according to any one of the numbers 1-6, wherein configuring the processor includes storing, on the processor, each footprint contained in the set of footprints as a value containing a plurality of bits indicating whether corresponding pixels are contained in the footprint. 8. Computer-implemented method according to one of the numbers 1-7, wherein the processor executes a plurality of lanes in a wave and each lane contained in the plurality of lanes processes a corresponding pixel contained in the set of pixels. 9. Computer-implemented method according to one of the numbers 1-8, wherein the processor is configured to sample a texel based on a filter for each lane contained in a plurality of lanes in a wave, to generate a texel sample, to compute a filtered value for each lane contained in the plurality of lanes based on a plurality of the texel samples read from a corresponding plurality of lanes, based on a footprint contained in the set of footprints associated with a pixel processing the lane, and to render at least one section of a graphic image based on the filtered values computed for the plurality of lanes. 10. Computer-implemented method according to one of the numbers 1-9, wherein the processor includes a graphics processing unit (GPU). 11. In some embodiments, one or more non-transitory computer-readable media store instructions which, when executed by at least one processor, cause the at least one processor to perform the following steps: generating a set of footprints based on a histogram of the number with which each pixel from a set of pixels is included in the set of footprints, wherein each footprint included in the set of footprints represents a plurality of pixels around a target pixel for reading texel samples, and configuring one or more processors to perform texture filtering using the set of footprints when one or more graphic images are rendered. 12. One or more non-transitory computer-readable media as defined in point 11, wherein generating the set of footprints includes performing one or more iterative optimization operations. 13. One or more non-transitory computer-readable media according to paragraphs 11 or 12, wherein generating the set of footprints comprises generating, for each pixel contained in the set of pixels, a corresponding set of pseudorandom footprints, selecting one pseudorandom footprint from the corresponding set of pseudorandom footprints, the set of footprints comprising the pseudorandom footprints to be selected, calculating a score based on the histogram, and determining that the score is a highest or a lowest score among one or more scores calculated for one or more sets of footprints. 14. One or more non-transitory computer-readable media according to any of the items 11-13, the assessment being calculated based on one standard deviation of the histogram. 15. One or more non-transitory computer-readable media according to one of the numbers 11-14, wherein the plurality of pixels around the target pixel is sampled based on a Gaussian distribution. 16. One or more non-transitory computer-readable media according to any of the items 11-15, wherein configuring the one or more processors includes storing the set of footprints in one or more lookup tables on the one or more processors. 17. One or more non-transitory computer-readable media according to any of the numbers 11-16, wherein the configuration of the one or more processors includes storing, on the one or more processors, each footprint contained in the set of footprints as a value containing a plurality of bits indicating whether corresponding pixels are contained in the footprint. 18. One or more non-transitory computer-readable media according to any of the digits 11-17, wherein the one or more processors are configured to compute one or more pixels contained in each footprint included in the set of footprints using one or more bit manipulations and arithmetic. 19. One or more non-transitory computer-readable media according to any of the numbers 11-18, wherein the set of pixels forms a rectangular region of the one or more graphic images. 20. In some embodiments, a system comprises one or more memories that store instructions and one or more processors coupled to the one or more memories which, when executing the instructions, are configured to: generate a set of footprints based on a histogram of the number with which each pixel from a set of pixels is included in the set of footprints, wherein each footprint included in the set of footprints represents a plurality of pixels around a target pixel for reading texel samples; and configure at least one processor to perform texture filtering using the set of footprints when one or more graphic frames are rendered.
[0100] Any and all combinations of any of the claim elements mentioned in any of the claims and / or any elements described in any way in this application fall within the intended scope of the present disclosure and protection.
[0101] The descriptions of the various embodiments are presented for illustrative purposes only and are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be obvious to the person skilled in the art without deviating from the scope and spirit of the described embodiments.
[0102] Aspects of the present embodiments may be embodied as a system, method, or computer program product. Accordingly, aspects of the present disclosure may take the form of a fully hardware embodiment, a fully software embodiment (including firmware, resident software, microcode, etc.), or an embodiment that combines software and hardware aspects, all of which may generally be referred to herein as a "module" or "system".
[0103] Any combination of one or more computer-readable media can be used. The computer-readable medium can be a computer-readable signaling medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or any suitable combination of the foregoing.More specific examples (a non-exhaustive list) of computer-readable storage medium would include the following: an electrical connection with one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, computer-readable storage medium can be any tangible medium capable of containing or storing a program for use by or in conjunction with an instruction execution system, device, or apparatus.
[0104] Aspects of the present disclosure are described above with reference to flowcharts and / or block diagrams of processes, devices (systems), and computer program products according to embodiments of the disclosure. It is understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing device to create a machine. When executed by the processor of the computer or other programmable data processing device, the instructions enable the implementation of the functions / steps specified in the block or blocks of the flowcharts and / or block diagrams.Such processors can be, without limitation, general-purpose processors, special-purpose processors, application-specific processors, or field-programmable gate arrays.
[0105] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, procedures, and computer program products according to various embodiments of the present disclosure. In this respect, each block in the flowcharts or block diagrams can represent a module, segment, or portion of code comprising one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions specified in the block may occur out of the order shown in the figures. For example, two blocks shown consecutively may actually be executed essentially simultaneously, or the blocks may sometimes be executed in reverse order, depending on the functionality involved.It is also noted that each block of the block diagrams and / or flowcharts and combinations of blocks in the block diagrams and / or flowcharts can be implemented by special-purpose hardware-based systems that perform the specified functions or steps, or combinations of special-purpose hardware and computer instructions.
[0106] While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the disclosure can be developed without deviating from its basic scope, and their scope is determined by the following claims. QUOTES INCLUDED IN THE DESCRIPTION
[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature
[0000] US 63 / 733,962
[0001] Cited non-patent literature
[0000] STOCHASTIC TEXTURE FILTERING THROUGH SINGLE INSTRUCTION MULTIPLE THREADS AND SINGLE INSTRUCTION MULTIPLE DATA LANE COMMUNICATION", filed December 13, 2024
[0001]
Claims
[1] Computer-implemented method for rendering graphic images, the method comprising: For each lane contained in a multitude of lanes in a wave, sample a texel based on a filter to generate a texel sample; For each lane contained within the multitude of lanes, calculate a filtered value based on a multitude of texel samples read by a corresponding multitude of lanes, based on a footprint associated with the lane; and Rendering at least one section of a graphic image based on the filtered values calculated for the multitude of lanes. [2] Computer-implemented method according to claim 1, wherein calculating the filtered value comprises: for each lane that is included in the corresponding multitude of lanes: Reading one or more coordinates, a sampled probability distribution function (PDF) value, and an initial texel sample associated with the lane, Calculating a weight based on one or more coordinates and the sampled PDF value, Adding the first Texel sample, weighted by its weight, to obtain an intermediate result, Adding the weight to an accumulation of weights; and Divide the intermediate result by the accumulation of weights to calculate the filtered value. [3] Computer-implemented method according to claim 1 or 2, wherein the plurality of texel samples is read from the corresponding plurality of lanes using wave intrinsics. [4] Computer-implemented method according to one of the preceding claims, wherein the plurality of texel samples is read from the corresponding plurality of lanes using quad intrinsics. [5] Computer-implemented method according to any of the preceding claims, wherein the footprint associated with the lane comprises at least one of a square footprint, a quad footprint or a pseudorandom footprint. [6] Computer-implemented method according to any of the preceding claims, wherein the plurality of corresponding lanes is determined based on either a lookup table, one or more bit manipulations and arithmetic, or a value containing a plurality of bits that specify the plurality of corresponding lanes. [7] Computer-implemented method according to any of the preceding claims, further comprising performing one or more iterative operations to generate a set of footprints that includes the footprint associated with the lane, based on a histogram of the number of pixels contained in the set of footprints. [8] Computer-implemented method according to any of the preceding claims, wherein calculating a filtered value for each lane comprises calculating a first filtered value for a first lane contained in the plurality of lanes by the following steps: Reading a first variety of the Texel sample from a first variety of Lanes based on a first footprint associated with the first lane; and in response to a determination that the first multitude of texel samples can be used in an exact filtering technique, performing the exact filtering technique to compute the first filtered value based on the first multitude of texel samples. [9] Computer-implemented method according to one of the preceding claims, wherein rendering the at least one section of the graphic image comprises performing at least one of one or more lighting operations or one or more shading operations. [10] Computer-implemented method according to any of the preceding claims, wherein the wave is executed via a graphics processing unit, GPU. [11] One or more non-transitory computer-readable media storing instructions which, when executed by at least one processor, cause that processor to perform the following steps: For each lane contained in a multitude of lanes in a wave, sample a texel based on a filter to generate a texel sample; For each lane contained within the multitude of lanes, calculate a filtered value based on a multitude of texel samples read by a corresponding multitude of lanes, based on a footprint associated with the lane; and Rendering at least one section of a graphic image based on the filtered values calculated for the multitude of lanes. [12] One or more non-transitory computer-readable media according to claim 11, wherein calculating the filtered value comprises: for each lane that is included in the corresponding multitude of lanes: Reading one or more coordinates, a sampled probability distribution function (PDF) value, and an initial texel sample associated with the lane, Calculating a weight based on one or more coordinates and the sampled PDF value, Adding the first Texel sample, weighted by its weight, to obtain an intermediate result, Adding the weight to an accumulation of weights; and Divide the intermediate result by the accumulation of weights to calculate the filtered value. [13] One or more non-transitory computer-readable media according to claim 11 or 12, wherein the plurality of texel samples from the corresponding plurality of lanes is read via at least one of wave intrinsics or quad intrinsics. [14] One or more non-transitory computer-readable media according to any one of claims 11 to 13, wherein the footprint associated with the lane comprises at least one of a square footprint, a pseudorandom footprint or a quad footprint. [15] One or more non-transitory computer-readable media according to any one of claims 11 to 14, wherein calculating the filtered value comprises performing an interpolation to mix the plurality of texel samples. [16] One or more non-transitory computer-readable media according to any one of claims 11 to 15, wherein the plurality of lanes corresponds to a plurality of adjacent pixels. [17] One or more non-transitory computer-readable media according to any one of claims 11 to 16, wherein rendering the at least one section of the graphic image comprises performing one or more denoising operations on the at least one section of the graphic image. [18] One or more non-transitory computer-readable media according to any one of claims 11 to 17, wherein the filter comprises either a bilinear filter or a bicubic filter. [19] One or more non-transitory computer-readable media according to any one of claims 11 to 18, wherein the at least one processor includes a graphics processing unit (GPU). [20] System, comprehensive: one or more memory locations that store instructions; and one or more processors coupled to one or more memories and, when executing instructions, configured to: For each lane contained in a multitude of lanes in a wave, sample a texel based on a filter to create a texel sample. For each lane contained within the multitude of lanes, calculate a filtered value based on a multitude of texel samples read by a corresponding multitude of lanes, based on a footprint associated with the lane, and Rendering at least one section of a graphic image based on the filtered values calculated for the multitude of lanes.
Citation Information
Patent Citations
63/733,962