Efficient fast random access enabled geometry attribute compression mechanism

Abstract

The graphics pipeline of a graphics processing unit includes a compressor that receives one or more (positional and non-positional) attributes of a vertex output from a vertex shader. The compressor determines the format of the one or more attributes and separates each attribute into parts based on the format of the attributes. The compressor compresses each part of the attributes based on the type of the parts. The compressed parts of the attributes are stored in an attribute storage device.

Description

Technology Field

[0001] The present invention relates to graphics processing units (GPUs). More specifically, the present invention relates to a front-end pipe (compression) of a GPU and a back-end pipe (decompression) of a GPU for compressing and decompressing positional and non-positional attribute data. Background Technology

[0002] Traditional computer graphics defines what needs to be designed in terms of the geometry of meshes. Meshes can be formed using vertices, and each vertex can possess several properties or attributes that define the object to be rendered. Examples of properties may include position, color, texture, normals, binormals, tangents, and various lighting variables. In computer graphics, these properties can be referred to as vertex attributes. The problem to be solved

[0003] The object of the present disclosure is to provide a method for compressing and decompressing positional and non-positional attribute data and a graphics processing unit. means of solving the problem

[0004] An exemplary embodiment provides a method comprising: determining the format of one or more attributes of a vertex output from a vertex shader, wherein the one or more attributes may include one or more positional attributes and one or more non-positional attributes; separating each of the one or more attributes into parts based on the format of the attributes; compressing each part of the attributes based on the type of the parts; and storing the compressed parts of the attributes of the vertex in memory. In one embodiment, the format of the first attribute may include a first floating-point format, and the parts of the first attribute of the floating-point format may include a sign part, an exponent part, and a mantissa part, and the step of compressing each of the first parts of the floating-point format comprises: compressing the sign part using run-length encoding; determining the first derivative of the exponent part; compressing the exponent part using zero-run encoding and Golomb-Rice coding; and determining the first derivative of the mantissa part. The method may include the step of compressing each part of the first attribute of the floating-point format by compressing the mantissa part using Colombe rice coding. In another embodiment, the format of the first attribute may include a fixed-point format, and the parts of the first attribute of the fixed-point format may include a sign part, an integer part, and a fractional part, and the step of compressing each part of the first attribute of the fixed-point format includes: the step of compressing the sign part using run-length encoding; the step of compressing the integer part using Colombe rice coding; and the step of compressing each part of the first attribute of the fixed-point format by compressing the fractional part using Colombe rice coding.In another embodiment, the format of the first attribute includes an integer format, and parts of the first attribute of the integer format may include a sign part and an integer part, and the step of compressing each part of the first attribute of the integer format may include: a step of compressing the sign part using run-length encoding; and a step of compressing each part of the attribute of the integer format by compressing the integer part using Colombe rice coding.

[0005] An exemplary embodiment includes the step of reading a compressed portion of a vertex attribute from memory; and

[0006] A method is provided that may include the step of decompressing the compressed portions of the above attributes, wherein run-length decoding is used based on the compressed portions including the sign portion of the above attributes; zero-run decoding and Colombe-Lies decoding are used based on the compressed portion including the exponent portion of the above attributes; and Colombe-Lies decoding is used based on the compressed portion including one of the mantissa portion, integer portion, and fraction portion of the above attributes.

[0007] An exemplary embodiment is a graphics pipeline of a graphics processing unit, wherein the graphics pipeline is a compressor that receives one or more attributes of a vertex output from a vertex shader, and the compressor may include a compressor that determines the format of each attribute, separates each attribute into parts based on the format of the attribute, compresses each part of the attribute based on the type of the part, and stores the compressed parts of the attribute in memory. Effects of the invention

[0008] According to the present invention, location and non-location attribute data can be compressed and decompressed. Brief explanation of the drawing

[0009] In the following, aspects of the contents disclosed herein will be described with reference to exemplary embodiments illustrated in the drawings, where: FIG. 1 illustrates a high-level block diagram of an exemplary embodiment of a graphics pipeline; FIG. 2 illustrates a high-level block diagram of an exemplary embodiment of a graphics pipeline showing an attribute compression flow during binning in accordance with the contents disclosed herein; FIG. 3 illustrates a high-level block diagram of an exemplary embodiment of a graphics pipeline showing an attribute decompression flow after a binning step in accordance with the contents disclosed herein; FIG. 4 illustrates a more specific flowchart of an exemplary embodiment of attribute compression prior to the binning step according to the contents disclosed herein. FIG. 4 illustrates a more specific flowchart of an exemplary embodiment of attribute decompression after the binning step according to the contents disclosed herein. FIG. 5 illustrates an electronic device having a GPU having an attribute compressor that compresses positional and non-positional attribute data in accordance with the contents disclosed herein. Specific details for implementing the invention

[0010] In the following detailed description, numerous specific details are described to provide a complete understanding of the present disclosure. However, it will be understood by those skilled in the art that the embodiments disclosed herein may be practiced without these specific details. In other cases, known methods, procedures, parts, and circuits are not described in detail so as not to obscure the content disclosed herein.

[0011] Throughout this specification, references to “one embodiment” or “one embodiment” mean that a particular feature, structure, or characteristic described in association with that embodiment may be provided for at least one embodiment disclosed herein. Accordingly, the appearance of phrases “in one embodiment,” “in one embodiment,” or “according to one embodiment” (or other phrases having a similar meaning) in various places throughout this specification does not necessarily refer to the same embodiment. Furthermore, particular features, structures, or characteristics may be combined in any appropriate manner in one or more embodiments. In this regard, as used herein, the word “exemplary” means provided for “examples, cases, or illustrations.” Any embodiment described as “exemplary” herein is not to be interpreted as having a preference or advantage over other embodiments. Furthermore, particular features, structures, or characteristics may be combined in any appropriate manner in one or more embodiments. Also, depending on the context of the discussion herein, a singular term may have a corresponding plural form or plural term including that singular form. Similarly, hyphenated terms (e.g., “two-dimensional,” “pre-determined,” “pixel-specific,” etc.) may sometimes be used interchangeably with their corresponding non-hyphenated versions (e.g., “two-dimensional,” “pre-determined,” “pixel specific,” etc.), and words that start with a capital letter (e.g., “Counter Clock,” “Row Select,” etc.) may be used interchangeably with their corresponding non-capitalized versions (e.g., “counter clock,” “row select,” etc.).Such occasional interchangeability should not be regarded as inconsistent.

[0012] Additionally, depending on the context of the discussion herein, a singular term may have a corresponding plural form or plural term that includes the singular form. It should also be noted that the various drawings (including part drawings) shown and discussed herein are for illustrative purposes only and are not shown to size. Similarly, various waveforms and timing diagrams are shown for illustrative purposes only. For example, the size of some components may be exaggerated relative to others for clarity. Furthermore, where appropriately considered, reference numerals are repeated between the drawings to indicate corresponding and / or similar components.

[0013] The terms used herein are intended merely to describe a few exemplary embodiments and are not intended to limit the claimed content. As used herein, unless the context clearly indicates otherwise, the singular forms “one (a, an)” and “the” also include the plural forms. As used herein, the terms “comprising” and / or “comprising” define the presence of the mentioned features, integers, steps, actions, elements, and / or parts, and do not exclude the presence or addition of one or more other features, integers, steps, actions, elements, parts, and / or groups. The terms “first,” “second,” etc., used herein are used as indicators for nouns preceding each other and do not imply any form of order (e.g., spatial, temporal, logical, etc.) unless clearly defined otherwise. Additionally, the same reference numeral may be used across two or more drawings to refer to parts, components, blocks, circuits, units, or modules having the same or similar function. However, such use is merely for the simplification and ease of discussion of the city, and does not imply that the structural and design details of these parts or units are the same throughout all embodiments or that these commonly referenced parts / modules are the only method for carrying out some of the exemplary embodiments disclosed herein.

[0014] When an element or layer is referred to as being “on top of,” “connected to,” or “combined” with another element or layer, this means that it is directly on top of, connected to, or combined with that other element or layer, or that another element or layer may exist in between. Conversely, when an element is referred to as being “directly on top of,” “directly connected to,” or “directly combined” with another element or layer, no other element or layer exists in between. Similar reference numerals refer to similar elements throughout this invention. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0015] Terms used herein such as “first,” “second,” etc. are used as indications for nouns that precede one another and do not imply any form of order (e.g., spatial, temporal, logical, etc.) unless clearly defined otherwise. Additionally, the same reference numerals may be used across two or more drawings to refer to parts, components, blocks, circuits, units, or modules having the same or similar functions. However, such use is merely for the sake of simplicity and ease of illustration of the description and does not imply that the structural and design details of these parts or units are the same throughout all embodiments or that these commonly referenced parts / modules are the only way to carry out some of the exemplary embodiments disclosed herein.

[0016] Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by those skilled in the art to which this content pertains. It should also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant field, and should not be interpreted in an idealized or overly formal sense unless expressed otherwise in this document.

[0017] As used herein, the term “module” refers to any combination of software, firmware, and / or hardware configured to provide the functions described herein in relation to the module. Software may be implemented as software packages, code and / or instruction sets or instructions, and the term “hardware” as used in any embodiment described herein may include, for example, hardwired circuits, programmable circuits, state machine circuits, and / or firmware storing instructions executed by programmable circuits, for example, alone or in any combination. Modules may be implemented as circuits forming parts of a larger system, for example, but not limited to, an integrated circuit (IC), a system-on-chip (SoC), etc., either collectively or individually.

[0018] The present invention provides an effective compression technique for vertex attribute data (pre-vertex shader or post-vertex shader) that can save memory bandwidth and improve graphics processor unit (GPU) performance. More specifically, compression of attribute data (both positional and non-positional) can reduce post-binning pass aggregation off-chip memory traffic. The positional / non-positional attribute compression / decompression technique described herein can significantly reduce memory bandwidth for multiple vertex attribute fetches in multi-pass rendering designs. Furthermore, power can be saved compared to memory traffic associated with uncompressed attribute data due to the reduction of off-chip and on-chip provided by the compression of attribute data.

[0019] In one embodiment, the present invention provides compression of positional and non-positional vertex attributes. The compression of these attributes may be context-aware compression and context-unware compression. For context-aware compression, attributes may be separated into smaller blocks or chunks based on the attributes' components, and selected compression techniques may be applied to each different attribute component block. For example, by knowing the attribute type, such as position, color, or normal, the attributes may be separated into variable-sized components (e.g., sign, exponent, mantissa, fraction, integer), and compression techniques tailored to the component data may be used. The separation of attribute components may also include additional information regarding the potential range of data for specific components that can be compressed into specific components.

[0020] The attribute compression technology disclosed herein may be implemented as a hardware, software, and / or firmware module to provide a compressed compute shader that compresses a pre-vertex shader and / or post-vertex shader to generate a compressed list of attributes. To provide multi-stage, parallel, and fast random access encoding and decoding technologies capable of providing high-throughput and low-latency attribute compression and decompression technologies, simple but effective compression technologies such as delta compression, run-length encoding, zero encoding, and Golom-dice encoding may be used, but not limited thereto. Additionally, a custom run-length zero encoding technology that effectively compresses zeros in attribute data more effectively than traditional run-length encoding may be used.

[0021] One embodiment disclosed herein provides a post-vertex shader attribute type-aware / non-aware compression technique having block-in-block sequential access and cross-block random access capabilities and low average latency. The compression technique that can be used to compress attribute data may vary depending on the format of the attribute. Another embodiment disclosed herein provides a free vertex shader attribute type-aware / non-aware compression technique.

[0022] Header information for compressed attribute data and this compressed attribute data can be combined in a unified storage device to avoid latency associated with additional overhead associated with hierarchical memory access. Data components can use adjustable compression techniques along with zero encoding techniques that reduce overhead associated with traditional run-length encoding techniques, which can be optimized for sequential unnecessary data without the overhead of frequent fixed-size symbol encoding.

[0023] FIG. 1 illustrates a high-level block diagram of an exemplary embodiment of a shader core graphics pipeline (100). The shader core graphics pipeline (100) may include free vertex shader (VS) stages (101), a vertex shader (VS) (102), a shader output dispatch (103), a primitive assembly (104), and an attribute storage device (105) such as dynamic random access memory (DRAM). The stages of the graphics pipeline (100) usually follow the illustrated order, and one or more stages may operate as a path-through as required by the application.

[0024] During the first stage of the graphics rendering process, the free vertex shader stages (101) may fetch primitives from memory (not shown), perform some processing on the primitives, and then send the primitives to the VS (102). The VS (102) may perform transformations and some custom processing steps to process the three-dimensional (3D) geometry. The VS (102) may also perform front-end processing on the attributes associated with the vertices of the primitives. In addition to the VS (102), the graphics hardware rendering pipeline (100) may optionally include a hull shader (HS), a domain shader (DS), and a geometry shader (GS) (all not shown), depending on the application's requirements and the pipeline's capabilities.

[0025] The output of VS (102) is sent to the shader output dispatch (103), where positional attributes are sent to the primitive assembly (104) and non-positional attributes can be sent to the attribute storage device (105). The output of the primitive assembly (104) can also be sent to the attribute storage device (105). The shaded (positional and non-positional) attributes of the vertex shader stages (VS / HS / DS / GS) can be passed through the fragment processing pipeline (not shown).

[0026] Location / non-location attributes may be application-defined amounts, and the driver may arrange attributes in an attribute storage device (105) according to the application's request (in a manner defined by a graphics application programming interface (API)). Generally, attribute data is not compressed and may contain a significant amount of unnecessary data.

[0027] In traditional tile-based deferred-rendering (TBDR) designs, a complete set of geometry or a partially large set of geometry can be processed in vertex shader stages, and a complete per-tile overlapping geometry can be identified. Until fragment processing begins, the complete set of data can be held in (off-chip or on-chip) storage, either as a whole or grouped into batches. Storage arrays can contribute a significant amount of (on-chip and / or off-chip) memory traffic. Memory bandwidth, graphics performance, and power consumption can be closely related. Since many graphics applications are already memory-bound by nature, and based on TBDR processing, applications may experience a significant loss in performance due to vertex attributes stored in the traditional manner.

[0028] Vertex-shaded attributes can include both positional and non-positional attributes. Both positional and non-positional attributes are vectors that can contain many scalars per vector. An example of a positional attribute may use four scalars (X, Y, Z, W) as coordinates, where, for example, X can be the horizontal position in the image, Y can be the vertical position in the image, Z can be the depth or distance from the eye in the image, and W can be a homogeneous coordinate system that can be used to perform perspective-correct interpolation. Example post-vertex shading (VS / GS / HS / DS) for positional attributes may include 32-bit floating-point (F32), 16-bit floating-point (F16), other custom floating-point formats, and fixed-point (sign.integer bit.fraction bit). An example of a non-positional attribute is a color that can also use four scalars (R, G, B, A), where, for example, R represents an intensity value for red, G represents an intensity value for green, B represents an intensity value for blue, and A is a number between 0.0 (completely transparent) and 1.0 (opaque). Example formats of non-positional attributes may include F32 and a 16-bit floating-point number (F16).

[0029] Positional attributes are passed from the shader output dispatch (103) to the primitive assembly (104) and then to the attribute storage device (105) before binning. Both positional and non-positional attributes can be stored in the attribute storage device (105), and their size may vary depending on the special attributes and the format of the special attributes being processed. Binning may use only one block and a primitive indicator per bin up to the point of compressed primitive blocks and the primitives of those blocks.

[0030] The pre-VS stages (101) and VS (102) can fetch attributes from a vertex buffer object (VBO) (not shown). Batching may be limited based on a limited variable storage size. After being processed by VS (102), non-location attributes may be stored on the chip, in which case there will be no off-chip traffic. Post-vertex shader attributes, however, may be stored on the chip and / or off-chip.

[0031] FIG. 2 illustrates a high-level block diagram of an exemplary embodiment of a graphics hardware pipeline (200) showing an attribute compression flow prior to binning in accordance with the contents disclosed herein. The graphics hardware pipeline (200) may include a vertex shader (VS) (201), a shader output dispatch (202), a staging buffer (203), a primitive assembly (204), a rasterizer frontend (205), and an attribute storage device (206), such as off-chip DRAM. The rasterizer frontend (205) may include a binning engine (211), remap logic (212), an adaptive variable compressor (APC) (213), and other rasterizer-specific logic. Pre-vertex shader stages are not illustrated in FIG. 2. A portion of the shader core graphics pipeline (200) illustrated in FIG. 2 may be performed as a module and / or software and / or programmable logic using fixed-function hardware.

[0032] VS (201) can perform front-end processing on attributes associated with the vertices of primitives by performing transformations and one or more custom processes to process a 3D shape projected onto a 2D surface, for example. VS (201) can apply processing steps on the attributes and then output shaded attributes. In addition to VS (201), the shader core graphics pipeline (200) may optionally include a hull shader (HS), a domain shader (DS), a shape shader (GS), and a compute shader (CS) (all not shown) depending on the application requirements.

[0033] The output of VS (201) can be sent to a shader output dispatch (202). The shader output dispatch (202) can send positional attributes to a primitive assembly (203) and non-positional attributes to a staging buffer (204). The staging buffer (204) can provide a temporary staging area to hide any latency associated with the primitive assembly (203). The staging buffer (204) can also provide a temporary storage device where blocks of non-positional attribute data can be accumulated before being sent to the remap logic (212).

[0034] The output of the primitive assembly (203) can be sent to the binning engine (211). The position attribute data output from the binning engine (211) can be sent to the remap logic (212). The output of the staging buffer (204) can be sent to the remap logic (212). The remap logic (212) outputs the converted non-position attribute data and the converted position attribute data to the APC (213). The binning engine (211) can receive control information from the remap logic (212) related to the position attribute data.

[0035] In the front-end portion of the pipeline (200) (i.e., the free vertex stages and VS (210)), the processed data may be arranged in a vertex major data unit, which may also be referred to as an array-of-structure (AoS) data unit. In the back-end pipeline (205), the processed data may be arranged in an attribute major data unit, which may also be referred to as a structure-of-array (SoA). The remap engine (212) transfers non-position attribute data received from the staging buffer (204) and position attribute data received from the binning engine (211) from the AoS data unit to the SoA data unit.

[0036] As described in more detail in relation to FIG. 4a, the APC (213) compresses non-location attribute data and location attribute data. In one embodiment, the APC (213) may use lossless compression techniques such as, but not limited to, Golom-Lice encoding, delta compression, run-length encoding, and zero encoding. In another embodiment, lossy compression techniques may be used to further reduce traffic, even if the rendered image quality is reduced. Since the output of the back-end pipe (205) may not be immediately read back, the output of the back-end pipe (205) may be sent directly to a storage device (on-chip or off-chip) that bypasses any cache layer, so caching may not be required. Power consumption may also be reduced because the output of the back-end pipe (205) is sent directly to the storage device (206) rather than through a caching layer.

[0037] FIG. 3 illustrates a high-level block diagram of an exemplary embodiment of a fiber core graphics pipeline (200) showing an attribute decompression flow after a binning step in accordance with the contents disclosed herein. During attribute decompression, compressed attribute data is sent from a storage device (206) to a cache layer (207) by blocks. From the cache layer (207), the compressed attribute data is sent to an attribute fetcher (AF) (220) within an attribute decompression unit (APD). The APD (221) decompresses the attribute data based on the compression method, as indicated by the header information associated with the compressed attribute data. The decompressed attribute data may be temporarily stored in an attribute buffer (222). The attribute buffer (222) may respond to requests received from back-end pipe requests (223) and from a work scheduler (224) for non-location attribute data. Position attribute data can be sent to an on-chip buffer (225) within the pixel shader core (226). Part of the shader core graphics pipeline (200) illustrated in FIG. 3 can be implemented as a module using fixed-function hardware and / or as software and / or programmable logic.

[0038] FIG. 4a illustrates a more specific flowchart of an exemplary embodiment of attribute compression (400) prior to the binning step according to the contents disclosed herein. Attribute data may be arranged in attribute blocks for a back-end reuse window, for example, denoted as 401. In 402, an attribute block that may contain several waves is received by the APC (213) (Fig. 2). A wave may be a group of vertices and may also be referred to as a warp. In one embodiment, a wave may be 32 vertices and may not be fully packed. In another embodiment, a wave may be 32 or more vertices, or fewer than 32 vertices. A block may contain post-VS attributes from less than one, exactly one, or more than one wave. Attribute blocks may include additional compression-related information, such as per-component means for Golom-Lice (GR) coding, but not limited to. Golom-Lice encoding uses a pivot for effective compression. In other embodiments, a different pivot may be selected, but in one embodiment, a means per component was selected as the pivot. In 403, attribute type-aware component-level data may be extracted. For example, if the attribute is formatted in F32 or F16 format, sign data, exponent data, and mantissa data are extracted. If the attribute is formatted in a fixed-point format, sign data, integer data, and fractional data are extracted. If the attribute is in an integer format, sign data and integer data are extracted. In 404, any bias of the attribute data may be optionally subtracted from the attribute data. Any bias data may be obtained, for example, from a header associated with the attribute data.

[0039] In 405, if the extracted data is code data, the code data is compressed using a run-length encoding technique.

[0040] In 406, if the extracted data contains exponential data, a first derivative operation may be performed on the exponential data using, for example, an exclusive OR (XOR). In 407, the exponential data may be compressed using zero-run encoding, Colombe-Lice encoding, delta compression, run-length encoding, and zero encoding, without being limited thereto. Zero-run encoding encodes only the repeating zero values ​​in the exponential data using a run-length value for repeating zero values. Non-zero values ​​in the exponential data are not encoded.

[0041] In 408, if the extracted data includes mantissa, integer, and / or fractional data, a first derivative operation may be performed on the attribute data using, for example, an exclusive OR (XOR). In 409, the mantissa, integer, and / or fractional attribute data may be compressed using, but not limited to, Colombe-Lice encoding, delta compression, run-length encoding, and zero encoding. In one embodiment, zero-run encoding may be optionally used depending on the data type being processed.

[0042] The compressed data from 405, 407, and 409 can be output as compressed header data and encoded data in 410 and can be stored in a storage device (206) (Figs. 2 and 3).

[0043] FIG. 4b illustrates a more specific flowchart of an exemplary embodiment of attribute decompression (450) after a binning step in accordance with the contents disclosed herein. In one embodiment, attribute decompression (450) is the opposite of compression (400) of FIG. 4a. As the compressed attribute data (410) is accessed from the storage device (206) ( FIG. 2 and FIG. 3), the compressed header data may be used to separate the compressed attribute data into sign, exponent, and mantissa / integer / fraction data. The compressed sign data may be decompressed in 451, for example, using a run-length decoding technique. The compressed exponent data is compressed in 452, but not limited to, using Colomb-Reiss decoding, delta decompression, run-length decoding, zero decoding, and zero-run decoding techniques. The first derivative of the decompressed exponent data may be accumulated in 453. Compressed mantissa / integer / fractional data may be decompressed in 454, but not limited to, using Colomb-Rice decoding, delta decompression, run-length decoding, and zero decoding. In one embodiment, zero-run decoding may be optionally used depending on the type of data being processed. Primary mantissa / integer / fractional data may be accumulated in 455. In 456, each component of the decompressed attribute data may be combined, and in 457, the attribute data is useful for further processing as attribute blocks for a back-end reuse window, such as attribute blocks indicated by 401 in FIG. 4b. The attribute blocks may include additional compression-related information, such as means per component for GR, but not limited to.

[0044] FIG. 5 illustrates an electronic device (500) having a GPU having a back-end pipe of a shader core that compresses positional and non-positional attribute data according to the contents disclosed herein. The electronic device (500) may be used in, but is not limited to, a computing device, a personal digital assistant (PDA), a laptop computer, a mobile computer, a web tablet, a wireless phone, a cell phone, a smartphone, a digital music player, or a wired or wireless electronic device. The electronic device (500) may have a controller (510), an input / output device (520) such as, but not limited to, a keypad, a keyboard, a display, a touchscreen display, a camera, and / or an image sensor, a memory (530), an interface (540), a GPU (550), and an imaging processing unit (560) coupled to each other via a bus (570). The memory (530) may be configured to store command codes or user data used by the controller (510).

[0045] The electronic device (500) and various system components of the electronic device (500) may have a GPU having front-end and back-end pipes of shader cores that compress positional and non-positional attribute data according to the contents disclosed herein. The interface (540) may be configured to have a wireless interface configured to transmit and receive data to or from a wireless communication network using RF signals. The wireless interface (540) may have, for example, an antenna, a wireless transceiver, etc. The electronic system 500 may also include, but is not limited to, Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM), North American Digital Communications (NADC), Extended Time Division Multiple Access (E-TDMA), Wideband CDMA (WCDMA), CDMA2000, Wi-Fi, Municipal Wi-Fi (Muni Wi-Fi), Bluetooth, Digital Enhanced Cordless Telecommunications (DECT), Wireless USB (Wireless Universal Serial Bus), Flash-OFDM (Fast low-latency access with seamless handoff Orthogonal Frequency Division Multiplexing), IEEE 802.It can be used in communication interface protocols of communication systems such as 20, GPRS (General Packet Radio Service), iBurst, WiBro (Wireless Broadband), WiMAX, WiMAX-Advanced, UMTS-TDD (Universal Mobile Telecommunication Service - Time Division Duplex), HSPA (High Speed ​​Packet Access), EVDO (Evolution Data Optimized), LTE-Advanced (Long Term Evolution - Advanced), MMDS (Multichannel Multipoint Distribution Service), etc.

[0046] Embodiments of the contents and operations described herein may be implemented in digital electronic circuits, or in computer software, firmware, or hardware, including structures and structural equivalents disclosed herein, or in one or more combinations thereof. Embodiments of the contents described herein may be implemented in one or more computer programs, namely, one or more modules of computer program instructions encoded by a data processing device or on a computer storage medium for execution to control the operation thereof. Alternatively or additionally, to a suitable receiving device for execution by a data processing device, the program instructions may be encoded on an artificially generated radio signal, such as, for example, an electrical, optical, or electromagnetic signal generated by a machine to encode information for transmission. The computer storage medium may be a computer-readable storage device, a computer-readable substrate, a random or serial access memory array or device, or a combination thereof. Furthermore, while the computer storage medium is a non-propagating signal, the computer storage medium may be a source or destination of computer program instructions encoded on an artificially generated propagating signal. A computer storage medium may also be one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices) or may be included therein. Additionally, the operations described herein may be implemented as operations performed by a data processing device on data stored in one or more computer-readable storage devices or received from other sources.

[0047] While this specification may include many specific implementation details, such implementation details should not be interpreted as a limitation to the scope of the claims, but rather as a description of features specific to particular embodiments. Some features described in this specification in the context of separate embodiments may also be implemented in combination in one embodiment. Conversely, several features described in the context of one embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination. Furthermore, while features may be described as operating in any combination as originally claimed, one or more features from the claimed combination may be removed from the combination in some cases, and the claimed combination may be intended as a sub-combination or a variation of the sub-combination.

[0048] Similarly, it should be understood that although operations are depicted in a specific order in the drawings, to obtain the desired results, these operations must be performed in the specific order depicted or in a sequential order, or all depicted operations must be performed. In some cases, multitasking and parallel processing are advantageous. Furthermore, the separation of various system components in the above-described embodiments should not be understood as requiring such separation in all embodiments, and the described program components or systems should generally be understood as being integrated together in a single software product and packaged into multiple software products.

[0049] Accordingly, specific embodiments of the content have been described herein. Other embodiments are within the scope of the following claims. In some cases, the operations described in the claims may be performed in a different order and may also achieve desirable results. Furthermore, the processes illustrated in the accompanying drawings do not necessarily require the specific order or sequential order shown to obtain desirable results. In some embodiments, multitasking and parallel processing are advantageous.

[0050] As will be known to those skilled in the art, the innovative concept described herein may be modified and changed over a wide range of applications. Accordingly, the scope of the claimed content should not be limited to the specific exemplary teachings discussed above, but should instead be defined by the following claims. Explanation of the symbols

[0051] 101: Free vs. Stage 102: Vertex Shader (VS) 103: Shader Output Dispatch 104: Primitive Assembly 105: Attribute storage device

Claims

Claim 1 A method for operating graphics hardware, comprising: a step of determining the format of one or more attributes of a vertex output from a vertex shader, wherein the one or more attributes include one or more positional attributes and one or more non-positional attributes; a step of separating each of the one or more attributes into parts including at least one of a mantissa part, an exponent part, and an integer part and a sign part based on the format of the attributes; a step of compressing each part of the attributes by compressing the sign part using run-length encoding based on the type of the parts, and compressing at least one of the mantissa part, the exponent part, and the integer part using an encoding method different from the run-length encoding; and a step of storing the compressed parts of the attributes of the vertex in memory. Claim 2 A method according to claim 1, wherein the format of the first attribute among the one or more attributes comprises a floating-point format, and the parts of the first attribute of the floating-point format comprise the sign part, the exponent part, and the mantissa part, and the step of compressing each part of the first attribute of the floating-point format comprises: the step of determining the first derivative of the exponent part; the step of compressing the exponent part using zero-run encoding and Golomb-Rice coding; the step of determining the first derivative of the mantissa part; and the step of compressing the mantissa part using Golomb-Rice coding. Claim 3 In paragraph 2, the format of the second attribute among the one or more attributes comprises a fixed-point format, and parts of the second attribute of the fixed-point format comprise the sign part, the integer part, and the fractional part, and the step of compressing each part of the second attribute of the fixed-point format comprises: determining the first derivative of the integer part; compressing the integer part using Colomb-Lice coding; determining the first derivative of the fractional part; and compressing the fractional part using Colomb-Lice coding. Claim 4 In paragraph 3, the format of the third attribute among the one or more attributes includes an integer format, and parts of the third attribute of the integer format include the sign part and the integer part, and the step of compressing each part of the third attribute of the integer format further comprises: the step of determining the first derivative of the integer part; and the step of compressing the integer part using Colombe-Rice coding. Claim 5 In claim 1, the format of the first attribute among the one or more attributes includes a fixed-point format, and the parts of the first attribute of the fixed-point format include the sign part, the integer part, and A method comprising: a step of compressing each part of the first attribute of the fixed-point format including a fractional part, and further comprising: a step of compressing the integer part using Colombe rice coding; and a step of compressing the fractional part using Colombe rice coding. Claim 6 In claim 1, the format of the first attribute among the one or more attributes includes an integer format, and parts of the first attribute of the integer format include the sign part and the integer part, and the step of compressing each part of the first attribute of the integer format further includes the step of compressing the integer part using Colombe rice coding. Claim 7 A method according to claim 1, further comprising the step of remapping one or more attributes of the vertex shader from an array of structure arrays to a structure of array arrays. Claim 8 A method according to claim 1, further comprising: a step of reading compressed portions of a first attribute of the vertex from memory; and a step of decompressing the compressed portions of the first attribute, wherein the decompressing step comprises: a step of using run-length decoding based on a compressed portion including the sign portion of the first attribute; a step of using zero-run encoding and Colombe-Lyce decoding based on a compressed portion including the exponent portion of the first attribute; and a step of using Colombe-Lyce decoding based on a compressed portion including one of the mantissa portion, integer portion, and fraction portion of the first attribute. Claim 9 A method for operating graphics hardware, comprising: a step of reading a compressed portion of a vertex attribute from memory; and a step of decompressing the compressed portions of the attribute, comprising: using run-length decoding based on the compressed portions including the sign portion of the attribute; using zero-run decoding and Colombis decoding based on the compressed portion including the exponent portion of the attribute; and using Colombis decoding based on the compressed portion including one of the mantissa portion, integer portion, and fraction portion of the attribute. Claim 10 A method according to claim 9, further comprising the step of compressing parts of the attributes of the vertex, wherein the compressing step is performed by: determining the format of the attributes of the vertex; separating the attributes into parts based on the format of the attributes; compressing each part of the attributes based on the type of the parts; and storing the compressed parts of the attributes of the vertex in the memory.

Images