DE102015002581A1 - Mapping a multi-rate harm to monolithic programs - Google Patents

Abstract

In multi-rate shading, a coarse data hading phase is added to an existing pixel rate phase to significantly improve performance with minimal impact on image quality. Two shading phases, valued at different rates, can be mapped to a monolithic program running on single-instruction-command-multiple-data-processor (SIMD) machines. In one embodiment, the multi-rate shading enables a single rendering pass to execute a shading code at one or more different rates: per pixel group, per pixel and per sample.

Description

Cross-reference to related application

This is a non-provisional application claiming priority of provisional application Serial No. 61 / 974,602 filed April 3, 2014, which is expressly incorporated herein by reference.

background

A significant part of the performance costs in a 3D pipeline is attributed to pixel shading. Higher display resolutions and higher graphics quality, especially in hand-held devices, are incompatible with the requirement of minimizing power dissipation. It would therefore be particularly advantageous to make pixel shaders work more effectively.

Coarse pixel shading takes advantage of the fact that geometric occlusion typically causes details of higher frequency than surface shading, and shading is performed at a lower rate than in visibility testing. Coarse pixel shading is well-suited for displays with a high pixel density where the effects of reduced shading rates from normal viewing distances are barely perceptible. The shading rates may be further reduced in screen areas which are blurred or otherwise less noticeable to the user, for example in areas affected by motion or defocusing blur, or in areas outside the user's foveal vision.

It is difficult to capitalize on these opportunities on current graphics architectures where shaders operate at a per-pixel or per-sample rate. The shading rates can be coarsely controlled by changing the frame buffer resolution, but this does not allow for a finer-grained change in the shading rates, for example, per object, per triangle, or per image area, which are still coupled to the visibility sample rate.

Coarse pixel shading (CPS) is an architecture for changing shading rates in a rasterization pipeline while keeping the visibility sampling rate constant.

Many approaches have been proposed to improve shading efficiency by sampling the shading at a lower rate than the visibility sampling rate. Multiple-sample anti-aliasing (MSAA) is one such technique often supported by graphics processor hardware. MSAA stores multiple coverage samples (also called visibility scans) per pixel, but pixel shaders are executed only once for each pixel covered by a primitive. This is in contrast to oversampling, where shaders are executed once per covered sample.

Brief description of the drawing

Some embodiments will be described with reference to the following figures. Show it:

1 a coarse square pixel layout and its 4-width SIMD execution sequence according to one embodiment,

2 another coarse pixel layout and its 4-width SIMD execution sequence according to one embodiment,

3A 10 is a flow chart for a kernel for handling both coarse and pixel rate harming according to one embodiment;

3B a flowchart for a solid-state accelerator according to an embodiment,

4 a pipeline abstraction of rasterization levels,

5 a section of a graphics pipeline for coarse pixel shading,

6 a multi-rate shading with a coarse pixel quadrangle, planned in a single thread on a SIMD processor with a width of 4,

7 a block diagram of a data processing system according to an embodiment,

8th a block diagram of the in 7 represented processor according to an embodiment,

9 a block diagram of the graphics processor 7 according to an embodiment,

10 a block diagram of a graphics processing machine according to an embodiment,

11 a block diagram of a graphics processor according to another embodiment,

12 a thread execution logic for an embodiment,

13 a block diagram of a graphics processor execution unit command format according to an embodiment and

14 a graphics software architecture for one embodiment.

Detailed description

Coarse pixel shading (CPS) scans the shading and visibility in a decoupled manner. The pixel shading is conveniently evaluated via an image space fading grid and cached in a reuse memorization cache for regular or stochastic rasterization (SR). In another coarse pixel sampling approach, the shading in a parametric patch space is uniformly sampled in an optimized Reyes architecture. These techniques enable shading gratings with any grid spacing, thereby allowing for more flexible control of the shading rate, in accordance with some embodiments.

In multi-rate shading, a coarse data hading phase is added to the existing pixel rate phase to significantly improve performance with minimal impact on image quality, in accordance with some embodiments. Two shading phases, valued at different rates, can be mapped onto a monolithic program running on processor graphics single instruction multiple data (SIMD) machines. A monolithic program is a one-tier software whose execution does not depend on another program. In one embodiment, multi-rate shading allows a single rendering pass to execute a shading code at one or more different rates: per pixel group, per pixel and per sample.

A new assembly command (hard-function hardware accelerator interface) allows for rapid switching of program execution from the rough rate to the pixel rate within the same core program running on the SIMD engine.

The new hard-function logic, in some embodiments, speeds up the coarse-to-pixel mapping, which has a much lower complexity / cost than the logic required to manage separate programs. At the same time, the software overhead for using the new logic is minimal, so that the performance of monolithic programs is not hindered according to some embodiments.

1 Figure 12 shows an example of a multi-rate shader execution for a coarse pixel quad layout of 1x2 pixels mapped to a SIMD program for different coarse pixel layouts. A coarse pixel is a group of pixels that share the result of a single coarse pixel shader evaluation. 2 Figure 15 shows an example of multi-rate shader execution for a 2 x 2 coarse pixel quad layout. For simplicity, the diagrams show a 4-width SIMD rectangle, but this solution applies to quadrilaterals of arbitrary numbers mapped to wider SIMD machines. The numbers (0, 1, 2, 3) represent coarse pixels, while the capital letters (A, B, C, ...) represent pixels. The left side of each diagram shows a two-dimensional view of pixels after rasterization, with numbers / letters in a lighter text denoting unilluminated pixels. The right side shows the execution order of phases in a monolithic program on a SIMD machine.

In the first phase ("coarse phase"), all four SIMD paths execute coarse-pixel commands for a coarse-pixel quadrilateral. In the next phase (pixel phase # 1), the same SIMD paths are used to perform subsequent groups of pixel quads covered by the coarse quad. The set of pixel shader quads and their mapping to coarse pixels depend on both the coarse pixel layout (e.g., 1 × 1, 1 × 2, 2 × 1, 2 × 2, 2 × 4, 4 × 2, 4 × 4) and the rasterization mask (some Squares can be completely unlighted). Furthermore, the SIMD execution mask may be different for each group.

In Phase 1, where the first three pixels are illuminated and the fourth pixel is not illuminated, the execution mask is (1, 1, 1, 0) so that the unilluminated pixel is not executed. The coarse-to-pixel mapping for phase # 1 is (0, 1, 0, 1), or coarse pixel 0 is mapped to pixel A, coarse pixel 1 is mapped to pixel B, pixel C is also mapped to coarse pixel 0 and Pixel D is mapped to coarse pixel 1. For phase # 2, the coarse-to-pixel map is 2, 3, 2, 3. All of these pieces of information are unknown in shader compilation, which would add significant software overhead if the coarse-to-pixel transition were used an existing set of assembly instructions would be implemented in software.

• Pixel_Maske – Angabe, welche Pixel in jeder Gruppe beleuchtet sind
• Pixel_zu_Grob_Abbildung – Angabe eines übergeordneten Grobpixels für jedes Pixel (zum Vermischen von Zwischenphasendaten von Grobphasenausgaben verwendet)
• Pixel_Raten_Schwerpunkt – Pixelort des Schwerpunkts zum Bewerten von Eingangsattributen
• Nächste_Gruppe_Kennung – Kennung der nächsten zu verarbeitenden Pixelgruppe

The execution sequences on the right in the 1 and 2 show a monolithic program using a new assembly instruction (coarse-to-pixel rate switching) to reduce software overhead associated with phase transitions. The new command takes pixel_group_identifier as input and returns the following for each pixel group:

• Pixel_Mask - specifies which pixels in each group are illuminated
• Pixel_to_Grob_map - specifying a parent coarse pixel for each pixel (used to blend interphase data from coarse phase outputs)
• Pixel_Rate_Point - Pixel location of center of gravity for evaluating input attributes
• Next_group_identifier - Identifier of the next pixel group to be processed

The new command is an interface to the hard-function hardware accelerator. The accelerator determines a two-dimensional mapping of coarse squares onto pixel quadrilaterals and manages the variable extension of that image because the number of pixel quads to be processed depends on both the coarse square layout and the rasterization mask. In particular, the accelerator suppresses whole squares if all the pixels are not illuminated. With this approach, a monolithic shader program abstracts from specific coarse quad layouts and mappings and loops pixel groups until the hardware accelerator informs that processing is complete (Next_Group_Key = 0).

According to some embodiments, a single core executes programs for both coarse and pixel rate shading. According to some embodiments, the SIMD engine may be used in which the same paths are used for both coarse and pixel quads covered by the rough quads.

In the 3A Sequence shown can be realized in software, firmware and / or hardware. In software and firmware embodiments, it may be implemented by computer-executed instructions stored in one or more non-transitory computer-readable media such as a magnetic, optical, or semiconductor memory.

In the sequence 3A will, as in block 10 indicated, a coarse phase implemented for all groups or squares. This follows in block 12 the implementation of a pixel phase for each group using the coarse-to-pixel mapping and the execution mask so that the same SIMD paths can be used to perform both rough squares and pixel squares covered by the coarse squares.

Then, the sequence receives a pixel group identifier (pixel group identifier) (block 14 ) to identify a particular pixel group in the manner of a quadrilateral. The execution mask is based on the pixel lighting mask represented by the in 3B fixed function accelerator determined for the current pixel group (block 16 ). Then, the coarse-to-pixel mapping is used to pass custom interstitial data between corresponding coarse and pixel phases, as in block 18 is specified. The per-pixel input attribute values are determined, and the pixel rate shading phase becomes block for each group 20 executed. In block 22 the next group to be processed is identified.

According to some embodiments, a fixed-function accelerator may be implemented in software, firmware, and / or hardware. In software and firmware embodiments, the accelerator may be implemented by computer-readable instructions stored in one or more non-transitory computer-readable media, such as magnetic, optical, or semiconductor memories.

In the 3B represented sequence 30 may begin by receiving an identifier of a new pixel group, as in block 32 is specified. It determines a two-dimensional, coarse-to-pixel mapping. On this basis, it determines a new pixel group, managing a variable extension and suppression. For this quadrilateral, it is determined which pixels are illuminated, as in block 34 is specified. Then the coarse-to-pixel mapping for the group is defined, and the pixel locations and the barycentric shape become block 36 certainly. The 2D mapping from coarse pixels to pixel quads can be determined as in block 38 is specified. Then the variable extension of the image is managed, as in block 40 is specified. Finally, entire squares are suppressed if all pixels are unlit, as in block 42 is specified. The process continues cyclically when new pixel groups are received. The accelerator gives the new pixel group, its execution mask (block 16 out 3A ) and the coarse-to-pixel mapping for this group (block 18 out 3A ) back.

The unique interface and decomposition of functionality between software (SIMD program) and hardware (fixed function accelerator), according to one embodiment, enables efficient mapping of multi-rate skipping phases to a monolithic SIMD program. In one embodiment, this approach significantly reduces hardware complexity (logic, buffers) and does not degrade performance.

To allow shading at a rate lower than once per pixel, the notion of a coarse pixel (CP) is introduced. A CP is a set of N _x N _y pixels sharing the result of a single coarse pixel shader (CPS) rating. This is similar to the way multiple visibility samples share a single pixel shard score with MSAA, the difference being that the shading rate can be changed by changing the CP size. Groups of 2 × 2 CP, called coarse squares (CQ), are shaded at one time to facilitate calculating derivatives using finite differences.

Many applications can benefit from the ability to vary shading rates across different areas of the screen. To allow such variation of the shading rate, the screen may be divided into tiles of size T _x x T _y , while for each tile a different value of CP size is allowed. Each tile is mapped to a CQ shading grid with the selected CP size.

A simplified decoupled sampling technique can be achieved by avoiding overlapping shading lattices, thereby ensuring that each pixel clearly belongs to only one CQ. This can be achieved by limiting the CP sizes to a finite set of values, ensuring that the shading grid is perfectly aligned with the tile boundaries. Under this assumption, the shading technique can be summarized as follows:

To ensure a perfectly aligned grid of CQ within a tile, the CP sizes can be constrained so that the tile size is a common multiple (eg, the least common multiple (LCM)) of all allowed CQ sizes.

• • anhand Pro-Vertex-Shaderausgaben interpoliert werden,
• • unter Verwendung des Renderzustands auf einen konstanten Wert gelegt werden oder
• • als eine radiale Funktion von Bildschirmkoordinaten ausgedrückt werden.

A small number of modes that are easy to use can control CP size, but these modes are powerful enough to support a range of applications. In either case, the user need not directly specify a CP size but rather a pair of CP parameters (s _x , s _y ), thereby specifying the desired CP size. The CP parameters are then quantized to the nearest available CP size that meets or exceeds the requested shading rate. Based on the selected mode, the CP parameters (s _x , s _y )

• • interpolated using pro vertex shader outputs,
• • be set to a constant value using the rendering state or
• • expressed as a radial function of screen coordinates.

Controlling the CP parameters with a shader output is very flexible and allows many usage cases to be expressed.

For the sake of simplicity, constant CP parameters can be enabled. This is the least invasive method to add CPS to an existing application. The ability to use a radial function is especially included for foveal rendering. Because a radial function can not be robustly expressed using linear interpolation of pro-vertex attributes, a separate mode can be used for this special case.

To always meet the required shading rate, the CP size, N _x x N _y , is calculated by computing conservative lower limits for | s _x | and | s _y | within the tile and rounded to the nearest available CP size. The use of absolute values allows the use of negative CP parameters for a movement and defocusing blur.

wobei δ_x und δ_y die endlichen Differenzen der Texturkoordinaten entlang der x- bzw. der y-Achse sind. Die Werte von δ_x und δ_y werden anders als die CP-Größe, die einmal pro Kachel bewertet wird, für jedes CP bewertet. Die Kompensation des Textur-LODs erzeugt eine glatte Variation von Bildeinzelheiten, wodurch die Diskontinuitäten in der CP-Größe maskiert werden.There are two quantization sources of CP sizes. First, the CP size is scored only once per tile. Second, the CP size is quantized to one of the finite available CP sizes. These two sources cause discontinuities in the CP sizes to move from tile to tile, which can lead to visible tile transitions. To compensate for these discontinuities, the detail level (LOD) calculation of the texture scanner is extended to reflect the requested (unquantized) CP size. This can be done by scaling the finite differences of texture coordinates used to calculate the texture LOD value:

where δ _x and δ _{y are} the finite differences of the texture coordinates along the x and y axes, respectively. The values of δ _x and δ _y are evaluated for each CP other than the CP size, which is evaluated once per tile. The compensation of the texture LOD produces a smooth variation of image detail, masking the discontinuities in the CP size.

Although LOD compensation can be effective in many cases, there are some scenarios in which it may not be applicable, such as procedurally generated textures. In these cases, LOD compensation techniques may possibly be applied in user space based on the CP size and CP parameters available as shader inputs.

Shading can be performed at three different rates within the same rendering pass. Some of the shader calculations may be shifted at a rate lower than once per pixel, while certain high frequency effects per pixel or even per visibility sample may be evaluated to reduce aliasing. This is not possible with current graphics application program interfaces (API) because the pixel shader may be designed to run at the pixel or sample rate, but the two exclude each other. Conceptually, the single pixel shader stage of the graphics pipeline is divided into three distinct phases, one for each rate (see 2 ). Therefore, after a tile has been divided into coarse squares, each quad is heaped at one or more different rates, namely, per CP, per pixel, and per sample.

4 shows how the CPS can be integrated into an existing graphics pipeline. The rasterizer 41 Tests input primitive elements to generate quadrilateral fragments that undergo an early depth test (Block 43 ) and then for each tile on the screen in the tile buffer 44 be buffered. The buffered fragments are based on the coarse pixel size (block 50 ) in block 46 Shown on coarse pixels and rough squares, which are then in block 48 and are mapped into the output buffers. With a simplified decoupled sampling technique, rasterized samples for a given tile and primitive elements in a tile buffer can be used 44 buffered, and then it becomes the pixelshader 48 called for finished CQ. The tiling buffer receives the screen coordinates and all the information needed to resolve the visibility in terms of the depth values and coverage information. When a new tile or a new primitive element is rasterized, the tile buffer is evicted so that only a single amount of data corresponding to a single tile needs to be buffered.

5 Figure 4 illustrates how CPS and multi-rate shading are integrated into the pipelined abstraction of an existing graphics architecture, such as Direct3D 11, to render targets 66 to create. Each shading phase has access to interpolated pro vertex attributes IA, and a small amount of data can be passed from one phase to another through user-defined shader outputs, with the allowable amount of data being an implementation-specific limit. Any of the phases (CP 60 , Pixels 62 , Sample 64 ) may also write outputs that are consumed in later pipeline stages (eg, frame buffer merging).

In multi-rate shading, a low frequency diffusion term per coarse pixel is calculated and a high frequency mirror term per pixel is calculated. The CP size is controlled by the vertex shader. In one embodiment, a single conceptual pipeline stage may execute a single shader compiled from up to three different entry points, with one associated with each rate, as shown below:

This approach provides programmers with a high degree of insight into and control over which code expires at each rate and which data flows between phases. The simpler models described above may still be implemented as layered abstractions in cases where control may be sacrificed for the sake of ease of use.

If the CP size is controlled by the shader code, an additional system interpreted value, SV_GrobPixelSize, of the last shading level before the rasterizer is made available. This output is a two-component vector and corresponds to the CP parameters (δ _x , δ _y ). Typically, this output is used in a vertex shader, but could also be defined in a shell, domain, or geometry shader, if used.

In addition, the shader code running at the CP rate has access to inputs for both the interpolated values of the CP parameters before quantization and for the actual coarse pixel size: SV_ requestedGrobPixelSize and SV_GrobPixelSize, respectively. These two values are sufficient for a shader to compute its own LOD compensation for use in calculations that do not include the texture scanner (for example, prefiltering a procedural texture).

There are several important uses cases where CPS can be used to significantly reduce the amount of pixel shading work. This is by no means an exhaustive list because there are many more uses.

Rendering to the native resolution of displays with high DPI values is often a demanding task for a graphics processing unit (GPU). The typical antidote is to reduce the rendered resolution and upsample the image, resulting in perceptible quality degradation along object silhouettes, while changes in interior surfaces are not so noticeable. Instead, by using CPS and setting the CP parameters to a constant value, such as 2 × 2 pixels, we can achieve a drastic reduction in the shading rate while retaining most of the details.

With more flexible control over the shading rate, a wider scope of application can be enabled, as discussed below.

Some materials have numerous surface details, while others do not. By choosing a CP parameter that depends on the material type, calculations can be saved where the visible influence is minimal. For example, a particle system may be quite homogeneous for rendering smoke and be shed at a low rate, while a character with text may justify shading at a higher resolution. Similarly, objects in a full shade may possibly be shaded at a lower rate than objects in bright sunlight.

CPS makes it easier to effectively shade with a foveal rendering, which avoids retransmitting a geometry over multiple render passes. A configurable radial function controls the shading rate with few parameters: the point c, which corresponds to the view center, the aspect ratio a, inner and outer small radii r ⁱ and r ^o, and inner and outer CP parameters s ^min and s ^max . For a foveal rendering, r ⁱ can be set to a size representing a viewing angle of about 5 ° and can be set for a circular truncation function a = 1.

While the shading system, in accordance with some embodiments, supports any location for the high resolution area, simply fixing c in the center of the screen and using a broader view produces good results, especially when rendering from a first-person perspective. This technique may be referred to as peripheral CPS rendering as opposed to actual foveal rendering, which is only possible with visual tracking.

Regions of the screen with a motion or defocus blur typically have a narrow frequency response and can be shaded at a lower rate. With CPS, the shading rate in these areas can be controlled by setting CP parameters in the vertex shader that are proportional to the screen space velocity or the confusion circle at that vertex. Because the vertex shader is scored before truncation, vertexes may be behind the camera or at a depth of zero. For these cases, the shading rate is not reduced to ensure robustness.

The CP parameters can be determined separately for the x and y axes to produce anisotropic shading rates for motion blur. By assigning negative CP parameters for vertexes before the focal plane and positive CP parameters for those behind, the CP parameters at the focal plane interpolate to zero. Similarly, assigning signed CP parameters for velocity ensures zero values at stationary points within a moving primitive element. Because the confusion circle radius of the screen space and the velocity are linear functions in the screen space, a perspective correct interpolation for the CP parameter should be disabled in these cases.

There are several different applications where multi-rate shading provides a valuable tool for scaling quality versus performance. The high quality ambient occlusion term is calculated using voxel-cone tracking every 2 x 2 pixels, while evaluating diffuse texture lookup values at a pixel rate to obtain as many surface details as possible. Similarly, complex low-frequency lighting calculations such as the calculation of indirect lighting at a lower rate can also be evaluated.

Another example is the local increase in shading rates in difficult areas. This can be done to calculate the shading at a pixel or sample rate only by specular features and otherwise compute at a lower rate. It is quite common in today's real-time workloads to implement one type of multi-rate harming using a two-pass approach. In this case, the first pass runs at the pixel rate (MSAA), but discards difficult pixels that are marked in a stencil buffer. The second pass then performs shading per sample, but only for pixels marked in the stencil buffer. Using CPS, these algorithms can be converted into a single pass that selectively calculates the result in pixel and sample rate shaders that yield results at even lower rates, if possible.

CPS multi-rate shading may also be used to perform paging on a per-CP (e.g., 4 x 4 pixels) basis.

A CPS software implementation is a pipeline in a central processor based on a Direct3D-11 functional simulator. For this implementation, a tile size of 16x16 pixels and CP widths and heights of 1, 2, or 4 may be used. To support the CPS programmer abstractions, the DirectX High Level Shading Language is extended and new API functions can be introduced. The simulator can be set up to measure the dynamic command count to give an indication of the cost of shading. All memory accesses to the color buffer can be tracked to measure color bandwidth.

In addition to pixel shading, a coarse pixel (CP) as well as a sample rate shading phase may be introduced into the pipeline. There are several possible implementation strategies for multi-rate shading depending on how these additional phases are scheduled across multiple processors and threads. In a scheduling strategy, the CP, pixel and sample rate slopes phases are executed one after the other on the same thread. Limiting the plan in this manner allows for easy implementation, with significantly fewer changes to the pipeline. This makes it unnecessary to transport data across phases because the data can remain in the same registers. This also avoids complex flow control mechanisms for throttling interphase data.

6 Figure 4 shows a coarse square with a CP size of 2 x 2 on a SIMD processor with a width of 4 with lanes 70 it's planned. First, the four CPs in the coarse square (for example 0123, 4567, ... 12131415) are added 72 simultaneously through the SIMD paths, thereby facilitating calculation of finite differences. After the coarse phase, the processor schedules 2 × 2 pixel quads simultaneously 74 within the rough rectangle, looping over all covered squares. Because this scheduling scheme requires a shift of data over SIMD lanes when transitioning between phases, we assume the availability of processor instructions to enable this effectively.

For SIMD widths greater than 4 (for example, 8 or 12), multiple coarse quads can be scheduled simultaneously. However, because each coarse square may have a different number of covered pixels, a higher SIMD width may also result in less use of some SIMD traces because some pixel phase loops will end sooner. For improved efficiency with large SIMD widths, a better scheduling scheme can be chosen that distributes pixel phase work more uniformly across SIMD lanes or even separate threads.

Shading at a rate lower than once per pixel has an impact on how well color buffer compression works for reducing memory bandwidth. Greater uniformity in color values within 2 x 2 pixel blocks or larger pixel blocks generally reduces entropy and makes compression more efficient. There are many existing color compression techniques that can benefit from CPS. To illustrate that this works in practice, the scheme of Pool et al. May be used which calculates color differences between pixels and then applies entropy coding over the differences using a Fibonacci encoder. Pool among others "Lossless Compression of Variable Precision Floating-Point Buffers on GPUs, Symposium on Interactive 3D Graphics and Games (2012), pp. 47-54 ,

The scheme of Pool u. a. can be modified so that the pixels are always visited using a predefined Hilbert curve in a hierarchical manner. Thereby, the differences are first calculated within a 2 × 2 quadrilateral and then within a 4 × 4 region and so on. When the CPS is activated, it is likely that several colors will be the same within some of these areas, producing zero differences that are effectively coded using a Fibonacci coder. We use a cache line size of 128 bytes, corresponding to 8x4 pixels for an RGBA8 render destination. When a line is ejected from the color cache, it is compressed, and if the resulting size is less than or equal to 64 bytes, compression is successful and the line is marked as compressed in a separate control buffer and written in only one 64-byte stream. Transaction sent to the store. Otherwise, the uncompressed data is sent to memory in two 64-byte transactions. A 64kB color cache is modeled using an Am At Least Recently Used (LRU) replacement policy.

Coarse pixel shading (CPS) can significantly reduce the cost of shadowing with little to no noticeable impact on image quality. Of course, the CPS fits in with the development of the real-time graphics pipeline because it introduces a new level of flexibility through programmable shading rates while still addressing a real need for energy efficiency for the fast growing handheld device market.

7 is a block diagram of a data processing system 100 according to one embodiment. The data processing system 100 has one or more processors 102 and one or more graphics processors 108 and may be a single-processor desktop system, a multi-processor workstation system, or a server system with a large number of processors 102 or processor cores 107 be. According to one embodiment, the data processing system 100 an integrated circuit system on a chip (SOC) for use in mobile, handheld or embedded devices.

An embodiment of the data processing system 100 may include or be included in a server-based gaming platform, game console, including a gaming and media console, a mobile gaming console, a handheld gaming console, or an online gaming console. According to one embodiment, the data processing system 100 a mobile phone, a smartphone, a tablet computing device, or a mobile internet device. The data processing system 100 may also include, be coupled to, or integrated with a wearable device, such as a smart-watch wearable device, a smart eyewear device, an augmented reality device, or a virtual reality device. According to one embodiment, the data processing system 100 a television or set-top box device having one or more processors 102 and a graphical interface provided by one or more graphics processors 108 is produced.

The one or more processors 102 each have one or more processor cores 107 to process instructions that, when executed, perform operations on system and user software. In one embodiment, each of the one or more processor cores 107 designed for a specific instruction set 109 to process. The instruction set 109 may facilitate a complex instruction set calculation (CISC), a reduced instruction set calculation (RISC), or a very long instruction word (VLIW) calculation. Multiple processor cores 107 can each have a different instruction set 109 which may have instructions for facilitating the emulation of other instruction sets. A processor core 107 may also include other processing devices such as a digital signal processor (DSP).

According to one embodiment, the processor 102 a cache 104 on. Depending on the architecture, the processor may 102 have a single internal cache or multiple levels of internal cache. According to one embodiment, the cache is between different components of the processor 102 divided. In one embodiment, the processor uses 102 also includes an external cache (eg, a Level 3 (L3) cache or a Last Level Cache (LLC)) (not shown) that uses known cache coherency techniques from the processor cores 107 can be used shared. A register file 106 is in addition to the processor 102 which may include various register types for storing various data types (eg, integer registers, floating point registers, status registers, and an instruction pointer register). Some registers may be general purpose registers while others may be registers for the design of the processor 102 can be specific.

The processor 102 is with a processor bus 110 coupled to data signals between the processor 102 and other components in the system 100 transferred to. The system 100 uses an example "hub" system architecture, including a memory control hub 116 and an input / output (I / O) control hub 130 , The storage control hub 116 facilitates communication between a storage device and other components of the system 100 while the I / O Control Hub (ICH) 130 Provides connections to I / O devices over a local I / O bus.

The storage device 120 For example, a Dynamic Random Access Memory (DRAM) device, a Static Random Access Memory (SRAM) device, a flash memory device, or other memory device with suitable performance to serve as a process memory. The memory 120 can data 122 and commands 121 for use when the processor 102 execute a process, save. The storage control hub 116 Also interfaces with an optional external graphics processor 112 that with the one or more graphics processors 108 in the processors 102 can communicate to perform graphics and media operations.

The ICH 130 allows peripheral devices to connect to the memory via a high-speed I / O bus 120 and the processor 102 get connected. The I / O peripherals include an audio controller 146 , a firmware interface 128 , a wireless transceiver 126 (eg WiFi, Bluetooth), a data storage device 124 (for example, a hard disk drive, a flash memory, etc.) and a legacy I / O controller for coupling legacy (eg, Personal System 2 (PS / 2)) devices to the system. One or more Universal Serial Bus (USB) controllers 142 include input devices such as keyboard and mouse combinations 144 at. A network controller 134 can also with the ICH 130 be coupled. According to one embodiment, a high performance network controller (not shown) is connected to the processor bus 110 coupled.

8th is a block diagram of one embodiment of a processor 200 with one or more processor cores 202A -N, an integrated memory controller 214 and an integrated graphics processor 208 , The processor 200 can add extra cores to an additional core 202N , which is represented by the dashed box, and including this. Each of the cores 202A -N has one or more internal cache units 204A -N up. In one embodiment, each core also has access to one or more shared cache units 206 ,

The internal cache units 204A -N and the shared cache units 206 represent a cache hierarchy within the processor 200 , The cache hierarchy may include at least one instruction level and data cache within each core, and one or more levels of a shared mid-level cache, such as level 2 (L2), level 3 (L3), level 4 (L4), or other cache levels. wherein the highest cache level before the external memory is classified as Last Level Cache (LLC). In one embodiment, cache coherency logic maintains coherency between the various cache units 206 and 204A -N upright.

The processor 200 may also be a set of one or more bus controllers 216 and a system agent 210 exhibit. The one or more bus controllers manage a set of peripheral buses, such as one or more peripheral component connection buses (eg, PCI, PCI Express). The system agent 210 provides management functionality to the various processor components. According to one embodiment, the system agent 210 one or more integrated memory controllers 214 for managing access to various external storage devices (not shown).

According to one embodiment, the one or more cores 202A -N support for concurrent multi-threading. According to this embodiment, the system agent 210 Components for coordinating and operating cores 202A -N during multi-thread processing. The system agent 210 may additionally include a power control unit (PCU) having logic and components to determine the power state of the cores 202A -N and the graphics processor 208 to regulate.

The processor 200 additionally has a graphics processor 208 for performing graphics processing operations. According to one embodiment, the graphics processor is 208 with the set of shared cache units 206 and the system agent unit 210 including the one or more integrated memory controllers 214 , coupled. According to one embodiment, a display control device 211 with the graphics processor 208 coupled to the graphics processor output to one or more drive connected ads. The display controller 211 may be a separate module coupled to the graphics processor via at least one connection, or it may communicate with the graphics processor 208 or the system agent 210 be integrated.

According to one embodiment, a ring-based connection unit 212 used to the internal components of the processor 200 however, an alternative connection unit may be used, such as a point-to-point connection, a switched connection, or other techniques, including techniques well known in the art. According to one embodiment, the graphics processor is 208 over an I / O route 213 with the ring connection 212 coupled.

The example I / O route 213 represents at least one of several varieties of I / O connections, including a packet I / O connection that facilitates communication between different processor components, and an embedded high performance storage module 218 in the manner of an eDRAM module. According to one embodiment, each of the cores use 202A -N and the graphics processor 208 the embedded memory modules 218 as a shared last level cache.

According to one embodiment, the cores are 202A -N homogeneous cores, which execute the same instruction set architecture. According to another embodiment, the cores are 202A -N in relation to the instruction set architecture (ISA) heterogeneous, where one or more of the cores 202A -N execute a first instruction set while at least one of the other cores executes a subset of the first instruction set or another instruction set.

The processor 200 may be part of one or more substrates or implemented thereon using a number of process technologies, for example, complementary metal-oxide-semiconductor (CMOS), bipolar junction / complementary metal-oxide-semiconductor (BiCMOS) or N-type devices. Metal oxide semiconductor logic (NMOS logic). In addition, the processor can 200 be implemented on one or more chips or as an integrated system-on-a-chip (SOC) circuit with the illustrated components in addition to other components.

9 Fig. 10 is a block diagram of one embodiment of a graphics processor 300 , which may be a discrete graphics processing unit or may be a graphics processor integrated with multiple processing cores. In one embodiment, the graphics processor communicates via a memory mapped I / O interface with registers on the graphics processor and commands issued to the processor memory. The graphics processor 300 has a memory interface 314 to access memory. The storage interface 314 may be an interface to local memory, to one or more internal caches, to one or more shared external caches, and / or to system memory.

The graphics processor 300 also has a display controller 302 for driving display output data to a display device 320 on. The display controller 302 has hardware for one or more overlay layers for the display and composition of multiple video layers or user interface elements. According to one embodiment, the graphics processor 300 a video codec machine 306 to encode, decode or transcode media to, from or between one or more media encoding formats, including Moving Picture Experts Group (MPEG) formats such as MPEG-2, Advanced Video Encoding (AVC ) Formats, such as H.264 / MPEG-4 AVC, as well as the Society of Motion Picture and Television Engineers (SMPTE) -421M / VC-1 formats and the Joint Photographic Experts Group (JPEG) Formats, such as, but not limited to, JPEG and Motion JPEG (MJPEG) formats.

According to one embodiment, the graphics processor 300 a block image transfer (BLIT) engine 304 for performing two-dimensional (2D) rasterizer operations, including, for example, bit boundary block transfers. However, in one embodiment, 2D graphics operations are performed using one or more components of the graphics processing engine (GPE). 310 executed. The graphics processing machine 310 is a calculator for performing graphics operations, including three-dimensional (3D) graphics operations and media operations.

The GPE 310 has a 3D pipeline 312 for performing 3D operations in the manner of rendering three-dimensional images and scenes using processing functions that affect primitive 3D shapes (eg, rectangle, triangle, etc.). The 3D pipeline 312 has programmable and fixed function elements that perform various tasks within the element and / or Execution threads for a 3D / media subsystem 315 bring forth. Although the 3D pipeline 312 for the execution of media operations, an embodiment of the GPE 310 also a media pipeline 316 specifically used for performing media operations such as video post-processing and image enhancement.

According to one embodiment, the media pipeline 316 Fixed-function or programmable logic units to perform one or more specialized media operations such as video decode acceleration, video de-interlacing, and video encoding acceleration in place of the video codec engine 306 or perform for this. According to one embodiment, the media pipeline 316 additionally, a thread spawning unit to execute threads on the 3D / media subsystem 315 produce. The spawned threads perform calculations for the media operations on one or more graphics execution units included in the 3D / Media subsystem.

The 3D / media subsystem 315 has logic to move from the 3D pipeline 312 and the media pipeline 316 execute spawned threads. According to one embodiment, the pipelines send thread execution requests to the 3D / media subsystem 315 which has thread dispatching logic to assess and handle the various requirements of available thread execution resources. The execution resources comprise an array of graphics execution units for processing the 3D and media threads. According to one embodiment, the 3D / media subsystem 315 One or more internal caches for thread commands and data. In one embodiment, the subsystem also includes shared memory including registers and addressable memory to share data between threads and to store output data.

10 Fig. 10 is a block diagram of one embodiment of a graphics processing engine 410 for a graphics processor. According to one embodiment, the graphics processing machine (GPE) is 410 a version of in 9 represented GPE 310 , The GPE 410 has a 3D pipeline 412 and a media pipeline 416 on, respectively, from the implementations of the 3D pipeline 312 and the media pipeline 316 out 9 may be different or similar.

In one embodiment, the GPE couples 410 with a command streamer 403 , which provides a command stream for the GPE-3D and media pipelines 412 . 416 provides. The command streamer 403 is coupled to the memory, which may be a system memory or one or more of the internal cache and a shared cache. The command streamer 403 receives commands from memory and sends the commands to the 3D pipeline 412 and / or the media pipeline 416 , The 3D and media pipelines process the instructions by performing operations by logic within the respective pipelines or by passing one or more execution threads to the execution unit field 414 , According to one embodiment, the execution unit field is 414 scalable so that the field has a variable number of execution units based on the GPE's target performance and performance level 410 having.

A scanning machine 430 couples to memory (for example, the cache or system memory) and the execution unit field 414 , According to one embodiment, the scanning engine 430 a memory access mechanism for the scalable execution unit field 414 ready, which it the execution field 414 allows to read graphics and media data from memory. According to one embodiment, the scanning machine 430 Logic for performing specialized image scanning for media.

The specialized media scanning logic in the scanning machine 430 has a noise removal / deinterlacing module 432 , a motion estimation module 434 and an image scaling and filtering module 436 on. The noise removal / deinterlacing module 432 includes logic for executing one or more noise removal or deinterlace algorithms on decoded video data. The deinterlacing logic combines alternating fields of interlaced video content into a single video frame. The noise removal logic reduces or removes data noise from video and image data. In one embodiment, the noise removal logic and deinterlacing logic are motion adaptive and utilize spatial or temporal filtering based on the amount of motion detected in the video data. According to one embodiment, the noise removal / deinterlacing module 432 a dedicated motion detection logic (eg, within the motion estimation engine 434 ) on.

The motion estimation machine 434 provides hardware acceleration for video operations by performing video acceleration functions such as motion vector estimation and video acceleration functions Prediction of video data ready. The motion estimation engine determines motion vectors describing the transformation of image data between consecutive video frames. According to one embodiment, a graphics processor media codec uses the video motion estimation engine 434 to perform operations on video at the macroblock level, which may otherwise be computationally intensive using a general purpose processor. According to one embodiment, the motion estimation engine stands 434 In general, graphics processor components are available to support video decoding and editing functions that are sensitive or adaptive to the direction or amount of motion in video data.

The image scaling and filter module 436 performs image processing operations to improve the visual quality of generated images and generated video. In one embodiment, the scaling and filtering module processes 436 Image and video data during the scanning process before the data enters the execution unit field 414 to be provided.

According to one embodiment, the graphics processing engine 410 a data port 444 which provides graphics subsystems with an additional mechanism for accessing memory. The data port 444 facilitates memory access for operations, including render target writes, constant buffer reads, scratch memory space read / write, and media surface accesses. According to one embodiment, the data port 444 a cache memory space for cache accesses to the memory. The cache may be a single data cache or distributed in multiple caches for the multiple subsystems accessing memory via the data port (eg, a render buffer cache, a constant buffer cache, etc.). In one embodiment, threads executing on an execution unit in the execution unit field 414 with the data port by exchanging messages over a data distribution link containing the respective subsystems of the graphics processing engine 410 coupled.

11 Fig. 10 is a block diagram of another embodiment of a graphics processor. According to one embodiment, the graphics processor has a ring connection 502 , a pipeline frontend 504 , a media machine 537 and graphic cores 580A -N up. The ring connection 502 couples the graphics processor to other processing units, including other graphics processors or one or more general purpose processor cores. According to one embodiment, the graphics processor is one of many processors integrated into a multi-core processing system.

The graphics processor receives command stacks over the ring connection 502 , The incoming commands are through a command streamer 503 in the pipeline frontend 504 interpreted. The graphics processor has scalable execution logic to provide 3D geometry processing and media processing via the graphics core (graphics cores). 580A -N. For 3D geometry processing instructions, the command streamer executes 503 the commands of the geometry pipeline 536 to. For at least some media processing commands, the command streamer executes 503 the commands a Videofrontend 534 to, that with a media machine 537 coupled. The media machine 537 has a video quality machine (VQE) 530 for video and image post-processing and a multi-format encoding / decoding (MFX) engine 533 for providing hardware accelerated media data encoding and decoding. The geometry pipeline 536 and the media machine 537 each generate execution threads for the thread execution resources that are from at least one graphics kernel 580A to be provided.

The graphics processor has scalable thread execution resources with modular cores 580A -N (sometimes referred to as core slices), each containing several kernels 550A -N, 560A -N (sometimes referred to as core sub-slices). The graphics processor can be any number of graphics cores 580A to 580N exhibit. According to one embodiment, the graphics processor has a graphics core 580A with at least a first sub-core 550A and a second subkernel 560A on. According to another embodiment, the graphics processor is a low power processor with a single sub-core (e.g. 550A ). According to one embodiment, the graphics processor has multiple graphics cores 580A -N, which each have a set of first sub-kernels 550A -N and a set of second kernels 560A Have -N. Each sub kernel in the set of first sub kernels 550A -N has at least a first set of execution units 552A -N and media / texture scanners 554A -N up. Each sub kernel in the second sub kernel set 560A -N has at least a second set of execution units 562A -N and samplers 564A -N up. According to one embodiment, the respective lower cores divide 550A -N, 560A -N a set of shared resources 570A -N. In one embodiment, the shared resources include shared cache and pixel operation logic. Other shared resources may also be included in the various embodiments of the graphics processor.

12 shows a thread execution logic 600 with an array of processing elements used in accordance with one embodiment of a graphics processing engine. According to one embodiment, the thread execution logic 600 a thread handler 604 , an instruction cache 606 , a scalable execution unit field with multiple execution units 608A -N, a scanner 610 , a data cache 612 and a data port 614 on. According to one embodiment, the contained components are connected via a connection network which links the respective components. The thread execution logic 600 has one or more connections to the memory, such as the system memory or a cache, over one or more of the instruction cache 606 , from the data port 614 , from the scanner 610 and the execution unit field 608A -N up. According to one embodiment, each execution unit (for example 608A an individual vector processor capable of executing multiple concurrent threads and processing multiple data elements for each thread in parallel. The execution unit field 608A -N has any number of individual execution units.

According to one embodiment, the execution unit field becomes 608A -N used primarily for executing "shader" programs. According to one embodiment, the execution units lead in the field 608A -N a command set that has native support for many standard 3D graphics shader commands so that shader programs of graphics libraries (such as Direct 3D and OpenGL) are executed with a minimum translation. The execution units support vertex and geometry processing (e.g., vertices, geometry programs, vertex shaders), pixel processing (e.g., pixel shaders, fragment shaders), and general purpose processing (e.g., arithmetic and media shaders).

Each execution unit in the execution unit field 608A -N works on fields of data elements. The number of data items is the "run size" or the number of channels for the command. An execution channel is a logical execution unit for data element access, masking, and flow control within instructions. The number of channels may be independent of the number of physical ALU or FPU for a particular graphics processor. The execution units 608A -N support integer and floating-point data types.

The execution unit instruction set includes single instruction multiple data (SIMD) instructions. The various data elements can be stored as a packed data type in a register, and the execution unit processes the various elements based on the data size of the elements. For example, when processing a 256 bit wide vector, the 256 bits of the vector are stored in a register and the execution unit processes the vector as four separate 64-bit packed data elements (four word (QW) size data elements), eight separated 32-bit packed data elements (double word (DW) size data elements), sixteen 16-bit separate packed data elements (word (W) size data elements) or thirty-two separate 8-bit data elements (bytes - (B) -Sizes data elements). However, other vector widths and register sizes are possible.

One or more internal instruction caches (for example 606 ) are in the thread execution logic 600 included to cache thread instructions for the execution units. According to one embodiment, one or more data caches (for example 612 ) to cache thread data during thread execution. A scanner 610 is included to provide texture sampling for 3D operations and media sampling for media operations. According to one embodiment, the scanner 610 specialized texture or media scanning functionality for processing texture or media data during the scanning process before providing the sampled data to an execution unit.

During execution, the graphics and media pipelines send thread initiation requests via the thread origination and dispatch logic to the thread execution logic 600 , The thread execution logic 600 has a local thread handler 604 which assesses thread initiation requests from the graphics and media pipelines and the requested threads on one or more execution units 608A -N instantiated. For example, the geometry pipeline (for example 536 out 10 ) Vertex processing, tessellation, or geometry processing threads for thread execution logic 600 from. The thread handler 604 can also handle runtime thread origination requests from the executing shader programs.

Once a group of geometric objects has been processed and rasterized to pixel data, the pixel shader becomes 602 to further calculate output information and cause the results to be written to output surfaces (eg, color buffers, depth buffers, stencil buffers, etc.). In one embodiment, the pixel shader computes 602 the values of the various vertex attributes to be interpolated over the rasterized object. The pixelshader 602 then executes an API supplied pixel shader program. The pixel shader passes to execute the pixel shader program 602 Threads through the thread handler 604 to an execution unit (for example 608A ). The pixelshader 602 uses the texture sampling logic in the scanner 610 to access texture data in texture maps stored in memory. Arithmetic operations on the texture data and the input geometry data compute pixel color data for each geometric fragment or discard one or more pixels so that they are not further processed.

According to one embodiment, the data port 614 a memory access mechanism for the thread execution logic 600 ready to output processed data to the memory for processing on a graphics processor output pipeline. According to one embodiment, the data port 614 one or more caches (for example, the data cache 612 ) or is coupled to cache data for memory access over the data port.

13 Fig. 10 is a block diagram showing the instruction format of the graphics processor execution unit according to an embodiment. Access to the fixed-speed accelerator described above can be mapped to a command (send message) described here. In one embodiment, the graphics processor execution units support a set of instructions with instructions in multiple formats. The boxes shown in solid lines show the components that are generally included in an execution unit instruction, while the dashed lines have components that are optional or that are only included in a subset of the instructions. The instruction format described and discussed are macro instructions in that they are instructions supplied to the execution unit, unlike micro-operations resulting from instruction decoding once the instruction has been processed.

In one embodiment, the graphics processor execution units support instructions in a 128-bit format 710 natively. A compacted 64-bit command format 730 is available for some commands based on the selected command, command options, and the number of operands. The native 128-bit format 710 provides access to all command options, while some options and operations are in 64-bit format 730 are limited. The native commands are in 64-bit format 730 are available vary according to the embodiment. In one embodiment, the command is partially performed using a set of index values in an index field 713 compacted. The execution unit hardware refers to a set of compaction tables based on the index values and uses the compaction table outputs to reconstruct a native 128-bit format instruction 710 ,

For each format defines a command operation code 712 the operation that the execution unit should perform. The execution units execute each instruction in parallel across the multiple data elements of each operand. For example, in response to an add command, the execution unit performs a concurrent add operation over each color channel representing a texture element or pixel. By default, the execution unit executes each command over all data channels of the operands. A command panel 712 allows the control of certain execution options in the type of channel selection (e.g., predication) and the data channel order (e.g., blending). For 128-bit commands 710 limits an execution size field 716 the number of data channels that are executed in parallel. The execution size field 716 is intended for use in the compact 64-bit instruction format 730 not available.

Some execution unit instructions have up to three operands, including two source operands src0 720 , src1 722 and a goal 718 , In one embodiment, the execution units support double target instructions, wherein one of the targets is implied. Data manipulation instructions may include a third source operand (eg, SRC2 724 ), wherein the instruction operation code JJ12 determines the number of source operands. The last source operand of a command may be an immediate (eg, hard-coded) value passed with the command.

According to one embodiment, instructions based on opcode bit fields are grouped around opcode decoding 740 to simplify. For an 8-bit opcode, bits 4, 5, and 6 allow the execution unit to determine the type of opcode. The illustrated accurate opcode grouping is exemplary. According to one embodiment, a shift and logic operation code group 742 Data movement and logic instructions (for example, mov, cmp). The shift and logic group 742 splits the five most significant bits (MSB), where There are motion commands in the form of 0000xxxxb (for example 0x0x) and logic commands in the form of 0001xxxxb (for example 0x01) are present. A flow control command group 744 (for example, call, jmp) has commands in the form of 0010xxxxb (for example, 0x20). A mixed command group 746 has a command mixture including synchronization commands (eg, wait, send) in the form of 0011xxxxb (for example, 0x30). A parallel mathematical command group 748 has component-wise arithmetic commands (for example, add, mul) in the form of 0100xxxxb (for example, 0x40). The parallel mathematical group 748 performs the arithmetic operations in parallel via data channels. The vector mathematics group 750 has arithmetic commands (for example, dp4) in the form of 0101xxxxb (for example, 0x50). The vector mathematics group performs arithmetic calculations in the manner of dot product calculations on vector operands.

14 FIG. 10 illustrates an example graphics software architecture for a data processing system according to an embodiment. FIG. The software architecture has a 3D graphics application 1010 , an operating system 1020 and at least one processor 1030 on. The processor 1030 has a graphics processor 1032 and one or more processor cores 1034 for general purposes. The graphics application 1010 and the operating system 1020 are each in system memory 1050 of the data processing system.

According to one embodiment, the 3D graphics application includes 1010 one or more shader programs, which shader commands 1012 exhibit. The shader commands can be in a high-level shader language such as High Level Shader Language (HLSL) or OpenGL Shader Language (GLSL). The application also has executable commands 1014 in a machine language necessary for execution by the processor core 1034 is suitable for general purposes. The application also has graphic objects defined by vertex data 1016 on.

The operating system 1020 can be a Microsoft ^® Windows ^® operating system from Microsoft Corporation, a proprietary UNIX-like operating system or an open source UNIX-like operating system using a variant of the Linux kernel. If the Direct3D API is used, the operating system uses it 1020 a frontend shader compiler 1024 to compile any shader commands 1012 in HLSL in a lower level shader language. The compilation may be a real-time compilation, or the application may perform a split precompile. According to one embodiment, high level shaders are generated during compilation of the 3D graphics application 1010 Compiled in lower level shader.

The user-mode graphics driver 1026 can be a backend shader compiler 1027 to convert the shader commands 1012 contained in a hardware-specific representation. The shader compiler merges coarse and pixel rate phases into a monolithic program and adds "annealing code" around it, as described in connection with the earlier monolithic program description. When the OpenGL API is used, shader commands become 1012 in the high-level language GLSL for compilation to a user-mode graphics driver 1026 to hand over. The user-mode graphics driver uses kernel-mode operating functions 1028 for communication with a core mode graphics driver 1029 , The core mode graphics driver 1029 communicates with the graphics processor 1032 to handle instructions and commands.

To the extent that various operations or functions are described herein, they may be described or defined as hardware circuits, software code, commands, configurations, and / or data. The content may be in hardware logic or as directly executable software ("object" or "executable" form), source code, high level shader code intended for execution on a graphics engine, or low level assembly language code in a instruction set for a specific processor or Graphics core can be realized. The software content of the embodiments herein may be provided by an article of manufacture having the content stored thereon or by a method of operating a communications interface to send data over the communications interface.

A non-transitory machine-readable storage medium may cause a machine to perform the described functions or operations, and has a mechanism that stores information in a form accessible to a machine (eg, a computing device, an electronic system, etc.), such as writable / non-writable recordable media (e.g., read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc.). A communication interface has a mechanism that connects to a hard-wired, wireless, optical, etc. medium to communicate with another device such as a memory bus interface, processor bus interface, internet connection, disk controller, etc. The communication interface is configured to prepare the communication interface by providing configuration parameters or transmitting signals to provide a data signal describing the software content. The communication interface may be accessed by one or more commands or signals sent to the communication interface.

The following clauses and / or examples relate to further embodiments:
An example embodiment may be a method in which a coarse-to-pixel mapping is defined for a pixel group, coarse pixel shading is performed, and pixel shading is performed in a hardware processor for the group using the coarse-to-pixel mapping becomes. The method may also determine which pixels in the group are illuminated. The same core can also be used for coarse and pixel shading in the method. The method may also use a single-instruction-multiple-data-shader. In the method, the same paths can also be used for both coarse and pixel shading. The method may also perform pixel shading for the group after coarse shading has been performed on the group. The method may also use an instruction to switch program execution from a rough rate to a pixel rate in the same core program running on a single instruction multiple data engine. The method may also include coarse shading of multiple squares at a time and then successively pixel shading each of the squares.

Another exemplary embodiment may be a method in which coarse and pixel shading with phases are mapped into a monolithic single-instruction-multiple-data program, pixel locations in centroid space are determined, and a pixel group is suppressed if all the pixels in the Group are unlighted. In the method, a coarse-to-pixel map, a pixel lighting map, a pixel cluster, and centroids can be compiled in a solid-state accelerator. In the method, pixel rate phases may be implemented as a looped pass across pixel groups determined by the fixed function accelerator. In the method, an execution mask may be set in each loop, a coarse-to-pixel mapping may be used for blending interstitial data between coarse-to-pixel rate phases, and centroids may be used to assign per-pixel attributes in each loop pass interpolate.

In another exemplary embodiment, one or more non-transitory computer readable media is provided which stores instructions executed by a processor to execute a sequence defining a coarse-to-pixel mapping for a pixel group, coarse pixel shading and pixel shading is performed in a hardware processor for the group using the coarse-to-pixel mapping. The media may comprise the sequence, determining which pixels in the group are illuminated. The media may have the sequence using the same core for coarse and pixel shading. The media may comprise the sequence using a single-instruction-multiple-data-shader. The media may have the sequence using the same coarse and pixel shading paths. The media may comprise the sequence, with pixel shading for the group being performed after the coarse-casting of the group. The media may comprise the sequence wherein a command to switch program execution from the rough rate to the pixel rate is used in the same core program executing a single command multiple data engine. The media may comprise the sequence, with multiple rectangles currently being roughly shed and then consecutive pixel shading being performed on each of the quadrangles.

Another example embodiment may be an apparatus that performs a hard-disk processor to define a coarse-to-pixel mapping for a pixel group, coarse pixel shading, and pixel shading in a group hardware processor using the coarse-to-pixel Map and includes a memory coupled to the processor. The Apparatus may include the processor to determine which pixels in the group are illuminated. The device may include the processor to use the same core for coarse and pixel shading. The device may include the processor to use a single-instruction-multiple-data shader. The device may include the processor to use the same paths for both coarse and pixel shading. The device may include the processor to perform pixel shading on the group after coarse shading has been performed on the group. The apparatus may include the processor to use an instruction to switch program execution from the coarse rate to the pixel rate in the same core program executing a single instruction multiple data engine. The apparatus may include the processor for roughly shaving a plurality of quadrangles at a time and then performing pixel shading of each of the quadrangles sequentially. The device may include a memory control hub. The device may comprise a wireless transceiver.

Various components described herein may be a means for performing the described operations or functions. Each component described here has software, hardware or a combination of these. The components may be implemented as software modules, hardware modules, special purpose hardware (eg, application specific hardware, application specific integrated circuits (ASIC), digital signal processors (DSP), etc.), embedded controllers, hardwired circuits, and so on. Apart from what has been described herein, various modifications can be made to the disclosed embodiments and implementations of the invention without departing from its scope. Therefore, the explanations and examples given herein should be interpreted as illustrative and not in a limiting sense. The scope of the invention should be determined solely by reference to the following claims.

The graphics processing techniques described herein may be implemented in various hardware architectures. For example, graphics functionality can be integrated into a chipset. Alternatively, a discrete graphics processor may be used. In another embodiment, the graphics functions may be implemented by a general purpose processor, including a multi-core processor.

References made to "a single embodiment" or "an embodiment" in this specification mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one implementation that is well-defined This disclosure is included. Accordingly, instances of the term "a single embodiment" or "according to one embodiment" do not necessarily refer to the same embodiment. Further, the particular features, structures, or properties may be embodied in other suitable forms than the particular embodiment discussed, and all such forms may be covered by the claims of the present application.

Although a limited number of embodiments have been described, many modifications and variations will occur to those skilled in the art. It is intended by the appended claims to cover all such modifications and variations that fall within the true spirit and scope of this disclosure.

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited non-patent literature

• "Lossless Compression of Variable Precision Floating-Point Buffers on GPUs," Symposium on Interactive 3D Graphics and Games (2012), pp. 47-54 [0071]

Claims (25)

Method comprising the following steps: Defining a coarse-to-pixel mapping for a pixel group, Performing a coarse pixelhadings and Performing pixel shading in a hardware processor for the group using the coarse-to-pixel mapping. The method of claim 1, wherein it is determined which pixels in the group are illuminated. The method of claim 1, wherein the same core is used for coarse and pixel shading. The method of claim 3, wherein a single command multiple data shader is used. The method of claim 4, wherein the same traces are used for both coarse and pixel shading. The method of claim 1, wherein a pixel shading for the group is performed after performing coarse harming to the group. The method of claim 1, wherein an instruction to switch program execution from the rough rate to the pixel rate is used in the same core program executing a single instruction multiple data engine. The method of claim 1, wherein coarse shading of a plurality of quadrangles is performed at a time, and then pixel shading of each of the quadrangles is successively performed. Method comprising the following steps: Mapping coarse and pixel shading with phases into a monolithic single-instruction-multiple-data program, Determine pixel locations in center of gravity and Suppressing a pixel group if all the pixels in the group are unlit. The method of claim 9, wherein a coarse-to-pixel mapping, a pixel illumination mask, a pixel group, and centroids are compiled in a solid-state accelerator. The method of claim 10, wherein pixel rate phases are implemented as a loop over pixel groups determined by the fixed function accelerator. The method of claim 11, wherein an execution mask is set in each loop, a coarse-to-pixel map is used to blend interstep data between coarse-to-pixel rate phases, and centroids are used to interpolate per-pixel attributes in each loop pass , One or more non-transitory computer-readable media storing instructions executed by a processor to execute a sequence comprising the steps of: Defining a coarse-to-pixel mapping for a pixel group, Performing a coarse pixelhadings and Performing pixel shading in a hardware processor for the group using the coarse-to-pixel mapping. The media of claim 13, wherein the sequence determines which pixels in the group are illuminated. The media of claim 13, wherein the sequence uses the same core for coarse and pixel shading. The media of claim 15, wherein the sequence uses a single-instruction-multiple-data-shader. The media of claim 16, wherein the sequence uses the same paths for both coarse and pixel shading. The media of claim 13, wherein the sequence performs pixel shading on the group after coarse shading has been performed on the group. The media of claim 13, wherein the sequence uses a command to switch program execution from a rough rate to a pixel rate in the same core program executing a single command multiple data engine. The media of claim 13, wherein the sequence comprises coarse shading of a plurality of squares at a time and subsequent pixel shading of each of the squares in succession. Apparatus comprising: a hardware processor for defining a coarse-to-pixel mapping for a pixel group, performing a coarse pixeling, and performing pixel shading on a hardware processor for the group using the coarse-to-pixel mapping and a memory coupled to the processor. The apparatus of claim 21, wherein the processor determines which pixels in the group are illuminated. The apparatus of claim 21, wherein the processor uses the same core for coarse and pixel shading. The apparatus of claim 23, wherein the processor uses a single command of multiple data shaders. The apparatus of claim 24, wherein the processor uses the same paths for both coarse and pixel shading.

Images