Graphics processor, texture loading method, texture processing unit, device and medium

Abstract

The present disclosure provides a graphics processor, a texture loading method, a texture processing unit, a device and a medium, and relates to the technical field of image texture loading. The method comprises the following steps: uniformly distributing a texture loading instruction to the texture processing unit for execution, wherein the texture loading instruction comprises a texture cache loading instruction; and parsing and executing the texture loading instruction by the texture processing unit; wherein texture state information of the texture loading instruction is obtained by hardware parsing of the texture processing unit, and address calculation and data reading of the texture loading instruction are completed in an independent texture loading pipeline, and the texture loading pipeline is started in the texture processing unit. The technical solution can simplify the scheduling logic of the texture loading instruction, improve the compatibility of dynamic resources, improve the hardware utilization rate, and improve the reliability and execution efficiency of texture data access.

Description

Technical Field

[0001] This disclosure relates to the field of image texture loading technology, and more specifically, to a graphics processor, texture loading method, texture processing unit, device, and medium. Background Technology

[0002] Currently, Graphics Processing Units (GPUs) heavily rely on texture loading operations during rendering and image processing to achieve efficient access to texture data stored in video memory. In related technologies, texture loading typically requires selecting different data paths based on different instruction types. For example, loading instructions that do not involve reading texture state information can be processed by the Load Store Unit (LSU), while loading instructions involving parsing texture state information require a Texture Processing Unit (TPU) combined with specific loading instruction combinations, including sequentially executing TAP, DMA, and MOVE instructions. This multi-path, multi-instruction texture loading mode can meet basic needs in early fixed-texture-binding scenarios, but it has certain limitations when facing complex graphics rendering tasks.

[0003] As graphics applications become more complex and real-time rendering requirements increase, the above loading schemes in related technologies require the compiler to map different types of loading instructions to corresponding hardware paths and determine whether texture state information needs to be read. This leads to complex instruction scheduling logic and increases software development and maintenance costs. For example, if texture state information cannot be obtained in advance under a new generation of graphics interfaces (such as DirectX 12 which supports unbound resources), the traditional loading path will fail, thereby affecting the reliability and execution efficiency of texture data access.

[0004] Therefore, there is an urgent need in related technologies for a texture loading scheme that can reduce software-side logic judgments, simplify the instruction mapping process, and be compatible with complex texture resource types, so as to improve the texture access efficiency and adaptability of graphics processors in high-concurrency and high-load scenarios.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The purpose of this disclosure is to provide a graphics processor, texture loading method, texture processing unit, device, and medium, thereby simplifying the scheduling logic of texture loading instructions and improving the reliability and execution efficiency of texture data access.

[0007] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part by practice of this disclosure.

[0008] According to a first aspect of the present disclosure, a texture loading method for a graphics processor is provided, the graphics processor including a texture processing unit, the method comprising:

[0009] The texture loading instructions are uniformly assigned to the texture processing unit for execution, and the texture loading instructions include texture cache loading instructions;

[0010] The texture processing unit parses and executes the texture loading instruction.

[0011] The texture state information of the texture loading instruction is obtained by the hardware parsing of the texture processing unit, and the texture loading instruction completes address calculation and data reading in an independent texture loading pipeline, which is started in the texture processing unit.

[0012] In some example embodiments of this disclosure, based on the foregoing scheme, the texture processing unit includes a texture address generation subunit, a texture data decompression subunit, and a texture filtering subunit; the step of parsing and executing the texture loading instruction through the texture processing unit includes:

[0013] The texture address generation subunit parses the texture state information in the texture loading instruction and calculates the virtual storage address, and then sends a texture data loading request to the first-level cache unit based on the virtual storage address.

[0014] The texture data decompression subunit decompresses the texture data returned by the first-level cache unit to obtain the decompressed texture data.

[0015] The texture filtering subunit performs format conversion on the decompressed texture data and returns the converted texture data to the unified shading cluster.

[0016] In some example embodiments of this disclosure, based on the foregoing scheme, the step of parsing the texture state information in the texture loading instruction and calculating the virtual memory address through the texture address generation subunit includes:

[0017] Receive scheduling instructions from the unified shading cluster, the scheduling instructions including the texture loading instruction and the texture sampling instruction;

[0018] In response to detecting that the scheduling instruction is the texture loading instruction, a separate texture loading pipeline is started;

[0019] The texture coordinates and texture state information in the texture loading instruction are parsed, and the virtual storage address of the texture is calculated based on the texture coordinates; and

[0020] The texture state information is distributed to the texture data decompression subunit and the texture filtering subunit.

[0021] In some exemplary embodiments of this disclosure, based on the foregoing scheme, the step of decompressing the texture data returned by the first-level cache unit through the texture data decompression subunit to obtain decompressed texture data includes:

[0022] Receive texture data returned by the first-level cache unit;

[0023] If the texture data is in a compressed format, a decompression operation is performed to obtain the decompressed texture data, and the decompressed texture data is output to the texture filtering subunit.

[0024] In some example embodiments of this disclosure, based on the foregoing scheme, the step of performing format conversion on the decompressed texture data through the texture filtering subunit includes:

[0025] Receive the decompressed texture data and the texture status information sent by the texture address generation subunit;

[0026] The texture state information and the decompressed texture data are directly input into the format conversion circuit to perform data type conversion, and the converted texture data is obtained.

[0027] The converted texture data is output to the unified shading cluster.

[0028] In some exemplary embodiments of this disclosure, based on the foregoing scheme, the step of directly inputting the decompressed texture data into the format conversion circuit to perform data type conversion includes:

[0029] When starting an independent texture loading pipeline, a texture loading queue is created through the texture filtering subunit. The texture loading queue is used to receive the texture state information and transmit the texture state information to the format conversion circuit.

[0030] The texture loading pipeline is used to bypass the filtering interpolation calculation circuit in the texture filtering subunit and input the texture state information and the decompressed texture data to the format conversion circuit to perform data type conversion.

[0031] In some example embodiments of this disclosure, based on the foregoing scheme, the texture loading pipeline initiated by the texture address generation subunit reuses the hardware pipeline of the texture sampling instruction.

[0032] In some example embodiments of this disclosure, based on the foregoing scheme, the reuse includes:

[0033] The shared texture address generation subunit processes the address calculation circuit of the texture sampling instruction;

[0034] A shared texture data decompression subunit processes the data buffer circuit for the texture sampling instructions;

[0035] A shared texture filtering subunit processes the format conversion circuit of the texture sampling instructions;

[0036] The texture loading instruction and the texture sampling instruction are processed separately in timing via hardware control registers.

[0037] In some example embodiments of this disclosure, based on the foregoing scheme, the texture loading method for a graphics processor supports unbound texture resources.

[0038] In some example embodiments of this disclosure, based on the foregoing scheme, when calculating the virtual storage address, the texture address generation subunit selects either linear addressing mode or block addressing mode according to the texture state information in the texture loading instruction.

[0039] According to a second aspect of the present disclosure, a texture processing unit for a graphics processor is provided, comprising:

[0040] The texture address generation subunit is used to parse the texture loading instructions issued by the unified shader cluster in the graphics processor, calculate the virtual storage address based on the texture coordinates and texture state information in the texture loading instructions, and initiate a texture data loading request to the first-level cache unit based on the virtual storage address.

[0041] The texture data decompression subunit is electrically connected to the texture address generation subunit and the first-level cache unit, and is used to decompress the texture data returned by the first-level cache unit to obtain decompressed texture data;

[0042] The texture filtering subunit is electrically connected to the texture address generation subunit and the texture data decompression subunit, and is used to perform format conversion on the decompressed texture data and return the converted texture data to the unified shading cluster.

[0043] In some example embodiments of this disclosure, based on the foregoing scheme, the texture address generation subunit includes:

[0044] A scheduling interface circuit is configured to receive scheduling instructions from the unified shading cluster, the scheduling instructions including the texture loading instruction and the texture sampling instruction, and to start an independent texture loading pipeline when the scheduling instruction is detected to be the texture loading instruction;

[0045] The address calculation circuit is used to calculate the virtual storage address based on the texture coordinates and texture state information in the texture loading instruction;

[0046] A distribution circuit is used to distribute the texture state information to the texture data decompression subunit and the texture filtering subunit.

[0047] In some example embodiments of this disclosure, based on the foregoing scheme, the texture data decompression subunit includes:

[0048] A data caching circuit is used to receive texture data returned by the first-level cache unit;

[0049] The decompression and decoding circuit is used to perform decompression operations on the texture data, output the decompressed texture data, and transmit the decompressed texture data to the texture filtering subunit.

[0050] In some example embodiments of this disclosure, based on the foregoing scheme, the texture filtering subunit includes:

[0051] A texture loading queue buffer circuit is used to create a texture loading queue when starting an independent texture loading pipeline, the texture loading queue being used to receive the texture state information;

[0052] The format conversion circuit is used to receive the texture status information transmitted by the texture loading queue buffer circuit and the decompressed texture data transmitted by the texture data decompression subunit, and perform data type conversion on the decompressed texture data according to the texture status information to obtain the converted texture data.

[0053] An output interface circuit is used to output the converted texture data to the unified shading cluster.

[0054] The texture filtering subunit further includes a filter interpolation calculation circuit. The texture loading pipeline is used to bypass the filter interpolation calculation circuit and directly input the texture state information and the decompressed texture data to the format conversion circuit to perform data type conversion.

[0055] In some example embodiments of this disclosure, based on the foregoing scheme, the texture address generation subunit initiates a texture loading pipeline independent of the texture sampling instruction, and the texture loading pipeline reuses the hardware pipeline of the texture sampling instruction, the reuse including:

[0056] The texture loading pipeline shares the address calculation circuit of the texture address generation subunit to process the texture sampling instruction;

[0057] The texture loading pipeline shares a texture data decompression subunit to process the data cache circuit of the texture sampling instruction;

[0058] The texture loading pipeline shares a texture filtering subunit to process the format conversion circuit of the texture sampling instructions;

[0059] The texture loading instruction and the texture sampling instruction are processed separately in timing via hardware control registers.

[0060] According to a third aspect of the present disclosure, a graphics processor is provided, comprising:

[0061] Such as the texture processing unit in the second aspect;

[0062] A unified shading cluster is used to issue texture loading instructions to the texture processing unit, so that the texture processing unit can parse and execute the texture loading instructions.

[0063] According to a fourth aspect of the present disclosure, an electronic device is provided, comprising: a graphics processor as described in the third aspect; and a memory storing computer-readable instructions that, when executed by the graphics processor, implement the texture loading method for a graphics processor as described in the first aspect.

[0064] According to a fifth aspect of the present disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a graphics processor, implements the texture loading method for a graphics processor in the first aspect.

[0065] The technical solutions provided in this disclosure may have the following beneficial effects:

[0066] The texture loading method for a graphics processor in the example embodiments of this disclosure, on the one hand, by uniformly allocating all texture loading instructions to the texture processing unit and directly parsing the texture state information by hardware within the unit, avoids the complex logic of multi-path mapping and software pre-parsing for instruction types in related technologies. This effectively reduces the latency caused by path switching and redundant instruction calls, thereby improving the execution efficiency and response speed of texture loading. On the other hand, both texture cache loading instructions and texture image loading instructions are parsed and processed in a unified hardware module, and the texture state information is directly parsed by hardware. This avoids the problem of not being able to obtain the texture state in advance in scenarios without bound resources, and can maintain processing even when facing multiple texture types and dynamic binding requirements. The consistency and scalability of the path ensure the stability and compatibility of the data loading process in scenarios with dynamic resource binding. On the other hand, by implementing the joint processing of texture cache loading instructions and texture image loading instructions through unified processing logic, buffer-type textures and image-type textures no longer need to follow different loading paths. This can improve the adaptability of the texture processing unit in scenarios with multiple resource types and enhance the overall processing efficiency for complex rendering tasks. Furthermore, by centrally executing instructions and data processing through a single texture processing unit, the redundant configuration and idle waiting of hardware resources can be reduced, hardware utilization can be improved, and potential timing conflicts caused by multi-module coordination can be reduced. This helps to improve the overall load balance and data processing throughput of the graphics processor's internal pipeline.

[0067] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0068] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0069] Figure 1 The illustration schematically shows a flow diagram of a texture loading method for a graphics processor according to some embodiments of the present disclosure.

[0070] Figure 2 The illustration shows a schematic diagram of a process for loading texture data via a texture processing unit according to some embodiments of the present disclosure.

[0071] Figure 3 The illustration shows a flowchart of a unified parsing of texture loading instructions by a texture address generation subunit according to some embodiments of the present disclosure.

[0072] Figure 4 The illustration schematically shows a process diagram of initiating a separate texture loading pipeline in a texture processing unit to load texture data according to some embodiments of the present disclosure.

[0073] Figure 5 The schematic diagram illustrates a structural schematic of a texture processing unit for a graphics processor according to some embodiments of the present disclosure.

[0074] Figure 6 The schematic diagram illustrates the structure of a texture processing unit for a graphics processor according to other embodiments of the present disclosure.

[0075] Figure 7 The schematic diagram illustrates a structural schematic of a texture processing unit for a graphics processor according to some other embodiments of the present disclosure.

[0076] Figure 8 The schematic diagram illustrates a structural schematic of a texture processing unit for a graphics processor according to further embodiments of the present disclosure.

[0077] Figure 9 The illustration schematically shows a compositional diagram of a graphics processor according to some embodiments of the present disclosure.

[0078] Figure 10 The schematic diagram illustrates the structural schematic of a computer system of an electronic device according to some embodiments of the present disclosure.

[0079] Figure 11 A schematic diagram of a computer-readable storage medium according to some embodiments of the present disclosure is shown.

[0080] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0081] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

[0082] It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0083] Furthermore, the accompanying drawings are for illustrative purposes only and are not necessarily drawn to scale. The block diagrams shown in the drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0084] In this example embodiment, a texture loading method for a graphics processor is first provided, which can be applied to a terminal device with a graphics processor. Figure 1 The illustration schematically shows a flow diagram of a texture loading method for a graphics processor according to some embodiments of the present disclosure. Reference Figure 1 As shown, the texture loading method for a graphics processor may include the following steps:

[0085] Step S110: Allocate texture loading instructions to the texture processing unit for execution. The texture loading instructions include texture cache loading instructions.

[0086] Step S120: The texture loading instruction is parsed and executed by the texture processing unit; wherein the texture state information of the texture loading instruction is obtained by the hardware parsing of the texture processing unit, and the texture loading instruction completes address calculation and data reading in an independent texture loading pipeline, which is started in the texture processing unit.

[0087] According to the texture loading method for a graphics processor in this example embodiment, on the one hand, by uniformly allocating all texture loading instructions to the texture processing unit and directly parsing the texture state information by hardware within the unit, the complex logic of multi-path mapping and software pre-parsing for instruction types in related technologies is avoided. This effectively reduces the latency caused by path switching and redundant instruction calls, thereby improving the execution efficiency and response speed of texture loading. On the other hand, both texture cache loading instructions and texture image loading instructions are parsed and processed in a unified hardware module, and the texture state information is directly parsed by hardware. This avoids the problem of not being able to obtain the texture state in advance in scenarios without bound resources, and can maintain processing path when facing multiple texture types and dynamic binding requirements. The consistency and scalability of the path ensure the stability and compatibility of the data loading process in scenarios with dynamic resource binding. On the other hand, by implementing the joint processing of texture cache loading instructions and texture image loading instructions through unified processing logic, buffer-type textures and image-type textures no longer need to follow different loading paths. This can improve the adaptability of the texture processing unit in scenarios with multiple resource types and enhance the overall processing efficiency for complex rendering tasks. Furthermore, by centrally executing instructions and data processing through a single texture processing unit, the redundant configuration and idle waiting of hardware resources can be reduced, hardware utilization can be improved, and potential timing conflicts caused by multi-module coordination can be reduced. This helps to improve the overall load balance and data processing throughput of the graphics processor's internal pipeline.

[0088] The texture loading method for a graphics processor in this example embodiment will now be further described.

[0089] In step S110, texture loading instructions are uniformly assigned to the texture processing unit for execution, and the texture loading instructions include texture cache loading instructions.

[0090] In one example embodiment of this disclosure, the texture processing unit refers to a hardware module within the graphics processor (GPU) used to parse texture loading instructions, calculate virtual memory addresses, and perform data decompression and format conversion. The texture processing unit may contain multiple logic sub-circuits for collaboratively processing loading requests from the Unified Shading Cluster (MP). Upon receiving an external texture loading instruction, the texture processing unit can parse the texture coordinates, texture resource identifiers, and texture state information contained in the instruction into control parameters required for video memory access, and complete the transmission and preprocessing of the loaded data through its built-in hardware logic in an independent texture loading pipeline. In specific implementations, the texture processing unit can consist of a texture address generation sub-unit, a texture data decompression sub-unit, and a texture filtering sub-unit. Alternatively, the texture processing unit can share some hardware circuitry with the general-purpose graphics computing unit via on-chip programmable logic (such as a configurable control register set) to reduce chip area and improve scalability.

[0091] Texture loading instructions are instructions issued by the compiler or graphics driver to access texture data in video memory. Texture loading instructions can include texture cache loading instructions and texture image loading instructions. Texture cache loading instructions primarily target buffer-type texture resources (such as undefined data blocks stored in a unified buffer). These instructions can be load instructions that do not require reading texture state information; they can be processed directly through the Load Memory Unit (LSU) path. Texture image loading instructions, on the other hand, are used to access texture resources stored in image formatting. Through unified allocation, the texture processing unit no longer needs to determine whether to execute the instruction via the LSU or the texture processing path (TPU), reducing path branches and additional logical judgments.

[0092] In practical implementation, unified allocation can be accomplished collaboratively by a hardware instruction decoder, an instruction queue control module, and a texture address generator (TAG). For example, when decoding scheduling instructions issued by the upper-layer Unified Shading Cluster (USC), the hardware instruction decoder identifies the instruction type as a texture loading instruction (which could include texture buffer loading instructions and texture image loading instructions) and passes this identification result to the instruction queue control module. The instruction queue control module can then directly map the texture loading instruction to the entry queue of the Texture Processing Unit (TPU) based on the decoding result, triggering the parsing process of the texture address generator (TAG). Upon receiving the texture loading instruction, the texture address generator (TAG) uniformly parses the texture coordinates and texture state information fields in the instruction and performs unified identification and address calculation processing for BUFFER and IMAGE class texture resources at the hardware level. The texture addressing generation module TAG does not need to determine whether an instruction needs to read the texture state, nor does it need to distinguish between the LSU and TPU paths. Instead, it directly starts the same loading pipeline based on the instruction structure. In this way, all Load instructions (including Load instructions that do not need to read texture state information) are allocated to the TPU path for execution through the TAG module. This avoids the complex judgment logic in related technologies where the compiler or driver layer needs to select the LSU or TPU path based on the resource type, thus achieving hardware unification of the texture loading path.

[0093] In step S120, the texture loading instruction is parsed and executed by the texture processing unit; wherein the texture state information of the texture loading instruction is obtained by the hardware parsing of the texture processing unit, and the texture loading instruction completes address calculation and data reading in an independent texture loading pipeline, which is started in the texture processing unit.

[0094] In one example embodiment of this disclosure, the texture processing unit can extract parameters such as texture coordinates, resource identifiers, and access modes from the instruction field during the parsing phase, and generate virtual memory addresses based on its internal addressing logic to determine the corresponding video memory location. During the execution phase, it can initiate a load request to the L1 cache unit, receive the returned texture data, and perform necessary preprocessing. In a specific implementation, the parsing process can be completed by a texture address generation circuit, which uses hardware units such as adders, shifters, and lookup tables to map the two-dimensional or three-dimensional coordinate parameters in the texture loading instruction to video memory addresses. During the execution phase, a data decompression circuit and format conversion logic can decode the returned compressed texture data into a pixel format that the rendering unit can directly use.

[0095] The texture state information of texture loading instructions can be directly parsed by the texture processing unit in hardware, and all texture loading instructions complete address calculation and data reading in an independent texture loading pipeline started in the texture processing unit. Texture state information refers to a set of parameters describing the texture data access method, including texture dimension, format type, sampling mode, and boundary processing method. In this embodiment, the texture state information does not need to be read or configured by software in advance, but is automatically parsed by the texture processing unit through texture loading instructions and internal registers. Through built-in state decoding logic and configuration registers, the texture processing unit can determine the access strategy immediately after the texture loading instruction is issued.

[0096] An independent texture loading pipeline refers to a hardware path structure specifically designed for texture loading instructions. It operates independently of other instruction pipelines and includes address calculation, cache access, and data fetching stages, ensuring that texture data can be streamed. Optionally, the independent pipeline can also reuse some hardware resources of the sampling pipeline through dynamic scheduling, while avoiding resource conflicts through timing isolation in the hardware control registers. This embodiment does not impose special limitations on the hardware path structure of the texture loading pipeline.

[0097] By uniformly distributing texture loading instructions to the texture processing unit for execution, different types of texture loading requests are parsed and processed within the same hardware module. This reduces the compiler's judgment logic during the instruction mapping stage, lowers the scheduling complexity caused by multi-path branches, and improves the determinism of instruction issuance and hardware execution efficiency. The state information of texture loading instructions is directly parsed by the texture processing unit, avoiding the process of relying on software pre-reading of state information and configuring it through additional instructions, as is common in related technologies. When facing new graphics interfaces such as unbound resources, this ensures the timely acquisition and correct parsing of texture states, thus maintaining the stability and compatibility of the loading path even in scenarios with dynamic resource binding. All texture loading instructions complete address calculation and data reading through an independent texture loading pipeline within the texture processing unit. This structure avoids the need for... In key technologies, the latency and redundancy introduced by multi-path switching are mitigated by ensuring a concise and efficient processing path for texture data from instruction triggering to read return, thereby shortening loading response time and improving data transmission continuity. A unified processing logic enables the joint processing of texture cache loading instructions and texture image loading instructions, eliminating the need for buffer-type textures and image-type textures to follow separate loading paths. This enhances the adaptability of the texture processing unit in scenarios with multiple resource types and improves the overall processing efficiency of the system for complex rendering tasks. Centralized execution of instructions and data processing by a single texture processing unit reduces redundant hardware resource configuration and idle waiting, improves hardware resource utilization, reduces potential timing conflicts caused by multi-module coordination, and helps improve the overall load balance and data processing throughput of the graphics processor's internal pipeline.

[0098] The texture loading method for the graphics processor in steps S110 to S120 will be described in detail below.

[0099] In one example embodiment of this disclosure, the texture processing unit may include a texture address generation subunit, a texture data decompression subunit, and a texture filtering subunit. These subunits work together to parse texture loading instructions, decode data, and perform format conversion. Specifically, the texture address generation subunit parses the texture loading instructions and calculates the virtual memory address; the texture data decompression subunit processes the texture data returned from the cache unit and performs decompression; and the texture filtering subunit converts the format of the decompressed data and returns it to the unified shading cluster. These subunits cooperate to achieve hardware-level automated texture loading and data preprocessing for the texture processing unit, reducing the complexity of software control.

[0100] It can be done Figure 2 The steps described in the document implement the parsing and execution of texture loading instructions through the texture processing unit, see reference. Figure 2 As shown, it can specifically include:

[0101] Step S210: The texture address generation subunit parses the texture state information in the texture loading instruction and calculates the virtual storage address, and initiates a texture data loading request to the first-level cache unit according to the virtual storage address;

[0102] Step S220: The texture data returned by the first-level cache unit is decompressed by the texture data decompression subunit to obtain the decompressed texture data;

[0103] Step S230: Perform format conversion on the decompressed texture data through the texture filtering subunit, and return the converted texture data to the unified shading cluster.

[0104] The texture address generation subunit is a hardware logic module specifically designed to map texture coordinates and instruction parameters to video memory access addresses. It utilizes coordinate components (e.g., u, v, w coordinates) and state parameters (e.g., texture dimension, mipmap level) from the texture loading instruction to calculate the final virtual memory address through addition, multiplication, and address offset logic. When the texture processing unit parses and executes the texture loading instruction, it first receives and parses the texture state information from the instruction and calculates the virtual memory address of the target texture data based on the texture state information and texture coordinates.

[0105] After calculating the virtual memory address, the texture address generation subunit can initiate a texture data loading request to the first-level cache unit based on the virtual memory address. The texture data loading request can be directly transmitted to the cache control logic via the bus interface circuit. The cache unit checks whether the corresponding video memory data has been cached. If a cache miss occurs, the cache control logic initiates a video memory access, reads the target texture block from video memory, and stores it in the cache. Specifically, texture data loading requests can be queued using an address request queue, and the cache unit's control logic manages the cache through address tag comparison and data filling operations. Optionally, a multi-level cache structure or a unified memory access controller can be used to prioritize loading requests to further improve loading efficiency.

[0106] The texture data decompression subunit is a module specifically designed for hardware decoding of compressed texture data. It utilizes built-in decompression algorithms (such as block compression based on BCn format or other graphics compression standards) to restore compressed texture data to its original pixel data. After the L1 cache unit returns texture data, the decompression subunit receives this data and determines whether its storage format is compressed. If it is determined to be compressed, it decompresses it.

[0107] The concept of a texture filtering subunit refers to a hardware logic module used to perform necessary formatting processing on decompressed texture data. The texture filtering subunit can determine the data type (such as RGBA format, floating-point, or integer) based on texture state information and perform corresponding pixel data arrangement conversions. The decompressed texture data is output from the texture data decompression subunit to the texture filtering subunit, which receives this data and performs format conversion operations. The texture filtering subunit can at least contain format conversion circuitry, which can rearrange or convert the original pixel data into the data structure required by the unified shading cluster.

[0108] After the texture filtering subunit completes the format conversion of the decompressed texture data, it can return the converted texture data to the unified shading cluster. As the core rendering unit of the graphics processor, the unified shading cluster can directly receive this hardware-preprocessed data and perform subsequent rasterization or pixel shading calculations.

[0109] By dividing the texture processing unit into a texture address generation subunit, a texture data decompression subunit, and a texture filtering subunit, and performing address calculation, data decompression, and format conversion sequentially on the hardware pipeline, efficient loading and real-time processing of texture data can be achieved without relying on software preprocessing, reducing data transmission latency and improving rendering throughput.

[0110] In one example embodiment of this disclosure, it can be achieved through Figure 3 The steps described in the document implement parsing the texture state information in the texture loading instruction and calculating the virtual memory address through the texture address generation subunit. (Refer to...) Figure 3 As shown, it can specifically include:

[0111] Step S310: Receive a scheduling instruction from the unified shading cluster, the scheduling instruction including the texture loading instruction and the texture sampling instruction;

[0112] Step S320: In response to detecting that the scheduling instruction is the texture loading instruction, start an independent texture loading pipeline;

[0113] Step S330: Parse the texture coordinates and texture state information in the texture loading instruction, and calculate the virtual storage address of the texture based on the texture coordinates; and

[0114] Step S340: Distribute the texture state information to the texture data decompression subunit and the texture filtering subunit.

[0115] The scheduling instruction refers to the control instructions generated by the unified shading cluster and issued to the texture processing unit, used to trigger texture data loading or texture sampling operations. The texture address generation subunit can communicate directly with the unified shading cluster through the scheduling interface, receiving and parsing data packets from the instruction queue issued by the unified shading cluster.

[0116] After the texture address generation subunit receives a scheduling instruction, if it detects that the instruction is a texture loading instruction, it can start an independent texture loading pipeline. This independent texture loading pipeline is a dedicated hardware processing path for texture loading instructions, running in parallel with the texture sampling pipeline. The independent texture loading pipeline can be triggered by a dedicated set of hardware circuits through a separate queue and control signals, ensuring that the loading instruction is not interfered with by the sampling interpolation calculation unit. For example, a dedicated load queue can be configured within the texture address generation subunit, and the pipeline control logic pushes texture loading instructions into this queue sequentially. After the pipeline starts, the control logic bypasses the filtering interpolation circuit in the texture filtering subunit, retaining only data type conversion and return paths, thereby reducing instruction latency.

[0117] Texture coordinates refer to the set of parameters that specify the location of a target pixel in the texture mapping space, typically two-dimensional or three-dimensional coordinates. Texture state information refers to metadata describing the texture access method, including texture format, mipmap level, addressing mode, etc. During hardware resolution, the texture address generation subunit performs a series of logical operations based on the texture coordinates and state information. For example, it can calculate row and column offsets through shifting and addition, and then generate the corresponding virtual memory address according to the block storage or linear storage mode. In some optional implementations, the texture address generation subunit may include multiple pipeline stages, each responsible for a specific computational task. For example, the first stage performs texture coordinate normalization, the second stage performs address index offset, and the third stage completes virtual address concatenation and verification. Optionally, frequently used texture coordinate mapping relationships can be cached through a lookup table, thereby reducing computational latency in high-frequency access scenarios.

[0118] Distribution refers to the parallel transmission of parsed state information to subsequent processing modules via a hardware signal bus, ensuring that subsequent data decompression and format conversion proceed according to the correct access mode and data structure. For example, a state distribution circuit can be configured within the texture address generation subunit. This circuit can encode texture state information into standardized control signals, which can then be transmitted to the texture data decompression subunit and texture filtering subunit via point-to-point connections or a shared bus, respectively.

[0119] By initiating an independent texture loading pipeline during the parsing of scheduling instructions and distributing texture state information to the decompression and filtering modules, the loading instructions are ensured to be independent of the sampling instructions in the hardware path. This optimizes the data path and achieves parallelism in instruction scheduling, thereby improving texture loading efficiency and avoiding data contention.

[0120] In one example embodiment of this disclosure, the decompression of texture data returned by the first-level cache unit through the texture data decompression subunit to obtain decompressed texture data can be achieved through the following steps:

[0121] It can receive texture data returned by the first-level cache unit; if the texture data is in a compressed format, it performs a decompression operation to obtain the decompressed texture data and outputs the decompressed texture data to the texture filtering subunit.

[0122] The L1 cache unit is a hardware module in the graphics processing unit (GPU) used for high-speed data access. Its function is to reduce latency caused by video memory access and improve data throughput. The returned texture data may be stored in video memory in a compressed format to reduce video memory usage and bandwidth pressure.

[0123] The texture data decompression subunit refers to a hardware circuit module used to restore compressed texture data into raw pixel data that can be directly used by the rendering unit. The texture data decompression subunit can be connected to the first-level cache unit via a dedicated data interface, triggering the receive operation in the first cycle of data return. In some optional implementations, the texture data decompression subunit may at least include a data input / output buffer and a decompression algorithm hardware pipeline. The data input / output buffer can temporarily store data blocks returned from the first-level cache unit and transmit the data in blocks to the decompression algorithm hardware pipeline to ensure continuous texture data decompression operations.

[0124] Upon receiving texture data, the texture data decompression subunit can determine whether the texture data is in a compressed format. The principle behind determining the compression format is to check the status information carried in the texture loading instruction or to identify whether the data uses compressed encoding by parsing the data header fields. For example, it can determine whether the texture data is based on the Block Compression (BCn) format or other dedicated compression algorithms supported by the GPU. In specific implementations, the texture data decompression subunit has a built-in compression flag detection circuit. This circuit can quickly determine the data processing mode by checking the flag bits in the status register.

[0125] If the texture data is determined to be in a compressed format, the texture data decompression subunit performs a decompression operation to obtain the decompressed texture data. The principle of decompression is to reverse-engineer the pixel data according to a predefined compression algorithm on the decompression algorithm hardware pipeline. For example, stored block data can be restored into an original pixel matrix containing color channels and transparency information. The decompression algorithm hardware pipeline may include multiple stages of parallel computing units: the first stage is responsible for data block reassembly and offset correction; the second stage decodes the color channels; and the third stage performs pixel format conversion and error correction. To improve processing efficiency, the decompression process often adopts a pipelined parallel architecture, with each stage independently processing a portion of the data, allowing multiple data blocks to be processed simultaneously at different stages.

[0126] After decompression, the texture data decompression subunit can output the decompressed texture data to the texture filtering subunit. The output process can be performed via an internal data bus or dedicated interface circuitry, ensuring high-speed data transmission and synchronization between different modules. For example, the texture data decompression subunit can set up a circular buffer to cache the decompressed texture blocks and directly send the data to the texture filtering subunit via DMA (Direct Memory Access) or a hardware data path. Optionally, the texture data decompression subunit can also adopt a double-buffered structure, so that while some data is being decompressed, another portion is already being sent to the texture data decompression subunit for subsequent processing. This maximizes pipeline utilization, effectively reduces data waiting time, and ensures that the decompressed texture data can be seamlessly integrated into subsequent format conversion and rendering calculations, improving the execution efficiency and real-time response capability of the entire texture loading path.

[0127] By performing hardware decompression of the compressed data returned from the cache within the texture data decompression subunit, the memory bandwidth pressure and data transfer volume can be minimized. At the same time, the original pixel data can be directly restored in hardware, reducing software decoding overhead and improving the real-time performance of data decoding.

[0128] In one example embodiment of this disclosure, the format conversion of the decompressed texture data can be achieved through the texture filtering subunit via the following steps, specifically including:

[0129] It can receive decompressed texture data and texture status information issued by the texture address generation subunit; directly input the texture status information and decompressed texture data into the format conversion circuit to perform data type conversion and obtain the converted texture data; and output the converted texture data to the unified shading cluster.

[0130] The texture filtering subunit is a hardware module specifically designed for formatting and filtering texture data. The texture data decompression subunit typically decompresses texture data into a pixel matrix. This data format may differ from the pixel format required by the unified shading cluster, necessitating format conversion for compatibility. Texture state information is a key parameter controlling the format conversion process; for example, it may include texture configuration parameters such as target pixel format, number of channels, bit depth, and color space.

[0131] A format conversion circuit is a hardware logic module used to convert between different pixel formats. Its principle is to adjust the channel arrangement, bit width, and numerical range of the original data according to the format description in the texture state information, making it a standard format recognizable and usable by a unified shading cluster. For example, in some optional implementations, the format conversion circuit can internally employ parallel shifters, look-up tables (LUTs), and addition / multiplication units to rearrange the data and map its values. For instance, when converting RGB565 format to RGBA8888 format, it is necessary to separate the compressed color channels and expand their bit depth. To accelerate processing, the format conversion circuit typically executes in a pipelined mode: the first stage performs channel separation, the second stage performs numerical expansion and scaling, and the third stage performs channel concatenation output. Of course, the format conversion circuit can also use other methods to implement the format conversion operation; this embodiment does not specifically limit the format conversion method of the format conversion circuit.

[0132] The converted texture data can be output to the unified shading cluster. This output process can be completed through the output interface logic of the texture filtering subunit. This logic transmits the format-converted data to the unified shading cluster's data receive buffer via a high-speed bus or direct memory access. For example, the texture data decompression subunit can set up a circular buffer or a multi-level FIFO (First In First Out) queue to ensure that data is continuously and sequentially fed into the unified shading cluster during data transmission, meeting the needs of parallel shading operations. Ensuring that the format-converted texture data can be provided to the unified shading cluster in a timely manner for subsequent pixel shading and rendering processing can effectively shorten the overall latency of the rendering pipeline and improve the graphics processor's operating efficiency and frame rate performance.

[0133] By receiving decompressed data and status information through the texture filtering subunit and performing format conversion, texture data that conforms to the format required by the unified shading cluster can be directly output, avoiding additional data rearrangement and format conversion in the rendering pipeline, and improving data availability and overall smoothness in the rendering stage.

[0134] Optionally, the decompressed texture data can be directly input into the format conversion circuit for data type conversion through the following steps, which may include:

[0135] When starting an independent texture loading pipeline, a texture loading queue is created through a texture filtering subunit. The texture loading queue is used to receive texture state information and transmit the texture state information to the format conversion circuit. The texture loading pipeline bypasses the filtering interpolation calculation circuit in the texture filtering subunit and inputs the texture state information and the decompressed texture data to the format conversion circuit to perform data type conversion.

[0136] Compared to traditional texture sampling pipelines, the independent texture loading pipeline omits complex interpolation calculations and reuses only the necessary modules related to texture loading. The startup process can be initiated by a hardware trigger signal from the texture address generation subunit, opening a dedicated data path to receive decompressed texture data from the texture data decompression subunit and perform subsequent operations.

[0137] After the texture loading pipeline starts, the texture filtering subunit can create a texture loading queue. The texture loading queue is a hardware cache structure used to store the state parameters and data blocks required by the current loading task. Its function is to decouple the parsed texture state information from the data transmission process, ensuring that the format conversion circuit can obtain the correct parameters sequentially. For example, the principle of the texture loading queue can be to use a FIFO structure to cache and orderly output texture state information, and to use hardware control logic to schedule multiple loading instructions sequentially.

[0138] The texture loading pipeline bypasses the filtering and interpolation calculation circuit in the texture filtering subunit and inputs the texture state information and decompressed texture data to the format conversion circuit for data type conversion. The texture loading instruction does not involve complex sampling calculations and interpolation operations, so the decompressed texture data can be directly passed to the format conversion circuit, bypassing the filtering and interpolation calculation circuit. For example, in some optional implementations, a hardware multiplexer (MUX) can switch the data channel from the filtering and interpolation calculation circuit to a direct output path, allowing data to reach the format conversion circuit without passing through the filtering and interpolation calculation circuit. The texture state information and decompressed texture data can be synchronously input to the format conversion circuit from the state buffer register and data buffer, respectively. The latter performs channel rearrangement, bit width expansion, and data type mapping based on the target format parameters in the texture state information, thereby shortening the data transmission link and improving the overall response speed and throughput of the texture loading path.

[0139] By establishing a texture loading queue in an independent loading pipeline and bypassing the filtering interpolation calculation circuit, the computational burden and latency of the loading path can be significantly reduced, enabling texture data to be transmitted to the format conversion circuit via the shortest path, thereby improving loading response speed and data transmission efficiency.

[0140] In one example embodiment of this disclosure, the texture loading pipeline initiated by the texture address generation subunit reuses the hardware pipeline of the texture sampling instructions.

[0141] It should be noted that although the texture loading pipeline mentioned in this embodiment is independent, this does not conflict with the hardware pipeline for reusing texture sampling instructions at the logical and physical levels. Specifically, independence means that the texture loading pipeline is independent of the texture sampling path at the instruction scheduling and execution control level. That is, when the texture address generation subunit detects that the scheduling instruction is a texture loading instruction, it will independently start the corresponding loading pipeline, without sharing the same scheduling sequence or execution context with the sampling instruction, thereby logically achieving parallel scheduling and timing isolation of the two types of instructions. Reuse describes the shared relationship at the underlying hardware resource level. To avoid redundant design and resource waste, in this embodiment, the texture loading pipeline can reuse the existing calculation circuits and cache circuits in the texture sampling instruction path when performing operations such as address calculation, data decompression, and format conversion. For example, it can share the address calculation unit, data cache interface, and format conversion circuit. Under this reuse mechanism, the execution states of loading instructions and sampling instructions can be distinguished by hardware control registers, and the path control signal can ensure that the two types of instructions alternately use the same hardware units on the time axis without resource contention or scheduling conflicts. Therefore, independence reflects the independence of the logical path, while reuse reflects the sharing of physical resources. The combination of the two can not only ensure the independent scheduling of the texture loading pipeline in the execution process, but also effectively reduce hardware area and power consumption, and improve the utilization rate of hardware resources in the graphics processor. Through this design, the texture loading operation can not only have independent execution capability, but also make full use of the high-performance computing units of the existing sampling path, achieving dual optimization of instruction parallelism and hardware utilization.

[0142] By reusing the hardware pipeline of texture sampling instructions, the texture loading pipeline can make full use of existing hardware resources, reducing redundant design and lowering the occupancy of chip logic units. This not only ensures efficient texture loading but also avoids the hardware overhead caused by designing separate pipelines for loading and sampling in traditional solutions. Furthermore, through dynamic control and timing scheduling, this reuse mechanism can also improve the overall pipeline's processing parallelism, making the switching process between loading and sampling fast and seamless, ensuring the stability and performance of the graphics processor in high-concurrency rendering tasks.

[0143] Optionally, the multiplexing of the hardware pipeline for texture sampling instructions may include:

[0144] The shared texture address generation subunit processes the address calculation circuit of the texture sampling instruction; the shared texture data decompression subunit processes the data buffer circuit of the texture sampling instruction; and the shared texture filtering subunit processes the format conversion circuit of the texture sampling instruction. The texture loading instruction and the texture sampling instruction are processed separately via hardware control registers.

[0145] In this shared texture address generation subunit, when processing the address calculation circuit for texture sampling instructions, the texture loading pipeline inputs its parsed texture coordinates to the same address calculation circuit as the texture sampling instructions. The texture address generation subunit can internally include a multi-stage pipeline based on adders, multipliers, shifters, and lookup tables to map texture coordinates and state information to virtual addresses in video memory. The principle behind this sharing is that the mathematical operations performed by texture loading instructions and texture sampling instructions during address calculation are essentially the same, such as texture coordinate normalization, mipmap level offset, and texture block index calculation. A multiplexer (MUX) can switch the input source between loading and sampling instructions, and a state latch maintains the independent addressing parameters for each instruction.

[0146] In the data buffer circuit of the shared texture data decompression subunit for processing texture sampling instructions, the texture loading pipeline and the sampling pipeline share the same data receiving and decoding path. The data buffer circuit refers to a high-speed buffer structure used to store texture data blocks returned from the L1 cache unit. Through cache management logic and a FIFO structure, loaded data and sampled data can be queued sequentially on the same data path to maximize resource utilization. For example, a data arbitrator and request queue can be set up to ensure that when loading and sampling instructions issue data access requests simultaneously, non-conflicting access can be achieved according to priority strategies or timing logic.

[0147] When the shared texture filtering subunit processes the format conversion circuit for texture sampling instructions, the texture loading pipeline can directly use the format conversion circuit to perform the necessary data type conversion on the decompressed texture data, without going through the filtering interpolation calculation circuit in the texture filtering subunit.

[0148] Texture loading instructions and texture sampling instructions can be processed in separate timings using hardware control registers to ensure that the instructions do not interfere with each other. Hardware control registers are a set of hardware storage units used to store pipeline states, execution modes, and priority parameters. Their principle is to distinguish the runtime sequence of different instruction types by switching register values ​​during execution. For example, the corresponding register configuration can be loaded each time an instruction enters the pipeline; for instance, texture loading instructions may use no-interpolation mode, while texture sampling instructions may use interpolation mode. The execution order of the two is automatically arranged by hardware arbitration logic.

[0149] By sharing the address calculation circuit, data cache circuit, and format conversion circuit respectively, and using hardware control registers to separate the timing of loading and sampling, efficient multi-instruction scheduling can be achieved without adding extra hardware modules, avoiding path conflicts and improving the overall instruction parallelism.

[0150] In one example embodiment of this disclosure, the texture loading method for a graphics processor supports unbound texture resources.

[0151] In this context, unbound texture resources refer to texture data accessed in Bindless Resource mode without the need for fixed slots or predefined binding tables. Instead, resource handles or index information are directly passed through instruction parameters, and the hardware dynamically parses the corresponding texture state information at runtime. Bindless Resource mode leverages the dynamic matching between resource identifiers carried by texture loading instructions and video memory resource descriptors, enabling flexible resource access. For example, after receiving a loading instruction, the texture processing unit can extract the resource handle from the instruction parameters using its built-in resource index parsing circuitry and, combined with the internal descriptor table or dynamic resource mapping table, map the handle to the physical address and state information of video memory. In this structure, texture state information is no longer configured through fixed-bound registers but is parsed by the hardware on the fly during the execution of the loading instruction.

[0152] When loading unbound resources, the texture address generation subunit can calculate the corresponding virtual memory address based on the resource index and texture coordinates. This process differs from the fixed binding mode in that the texture state information of the texture resource (e.g., texture format, mipmap level, addressing mode, etc.) is not pre-written into a specific register, but is read from the dynamic resource descriptor in real time and input into the address calculation circuit.

[0153] In unbound resource mode, the texture data decompression and texture filtering subunits can automatically adjust their processing flow based on dynamically parsed texture state information. For example, when the resource descriptor identifies the texture data as compressed, the texture data decompression subunit will start the corresponding decompression algorithm module without needing to pre-configure a specific format flag register. Similarly, the texture filtering subunit will perform format conversion, data rearrangement, or type extension operations based on dynamic state information to ensure that the output data format is consistent with the input format required by the unified shading cluster.

[0154] By supporting a hardware architecture that supports unbound texture resources, loading failures caused by resource pre-configuration errors or insufficient binding slots in traditional fixed-binding methods can be avoided. By integrating dynamic resource resolution circuits and state information distribution logic into the texture processing unit, the loading instruction can quickly complete resource matching and data loading at runtime, thereby improving the graphics processor's adaptability in multi-rendering pipelines, virtual reality, and complex scene rendering.

[0155] In one example embodiment of this disclosure, when calculating the virtual memory address, the texture address generation subunit selects either linear addressing mode or block addressing mode based on the texture state information in the texture loading instruction.

[0156] Linear addressing mode refers to storing texture data contiguously in video memory in row-major or column-major order. Address calculation is typically achieved through formulaic addition and multiplication. When the texture state information indicates linear addressing mode, the texture address generation subunit can generate virtual memory addresses by performing arithmetic operations on texture coordinates and texture configuration parameters (including texture width, height, and number of channels). In this mode, texture data is arranged sequentially in video memory in row-major or column-major order, with a fixed span between rows or layers. In specific implementations, the address calculation circuit can use adders and multipliers to sequentially expand the texture coordinates along each dimension, mapping the two-dimensional or three-dimensional coordinates of the texture to a one-dimensional linear address. For example, in a two-dimensional texture scene, address calculation can use the formula:

[0157] Address=BaseAddr+(v×Width+u)×PixelSize;

[0158] Where BaseAddr is the base address, u and v are the texture coordinates, Width is the texture width, and PixelSize is the pixel size. The technical advantage of this mode lies in its simple computational logic and low resource consumption, making it suitable for texture resources with continuous access patterns and well-organized data.

[0159] Block addressing mode refers to storing texture data in fixed-size blocks (such as 4x4 pixel blocks or 8x8 pixel blocks) in video memory to optimize cache hit rate and improve video memory bandwidth utilization. Block addressing mode first calculates the block index of a pixel, then calculates the offset address of the pixel within that block, and combines the two to generate the final virtual memory address. When the texture state information indicates that block addressing mode is used, the texture address generation subunit can determine the virtual memory address through the block index calculation module and the intra-block offset module. The block index module obtains the block position by dividing the texture coordinates by the block size, and then combines it with the texture base address to determine the block start address; the intra-block offset module takes the modulo of the block size based on the texture coordinates to obtain the offset of the current pixel within the block, and combines this with the format information to calculate the final virtual memory address.

[0160] When selecting an addressing mode, the texture address generation subunit can dynamically determine the optimal addressing method based on the texture state information in the texture loading instruction, ensuring that the optimal addressing method is selected for different types of texture resources and rendering requirements. The texture state information may include a storage layout flag, which characterizes the organization and addressing characteristics of the texture resource in video memory. For example, the storage layout flag can consist of multiple bit fields, each corresponding to a storage attribute. For instance, the mode selection bit (L_MODE) can indicate the addressing mode type of the texture resource; when L_MODE is 0, it indicates linear addressing mode, and when L_MODE is 1, it indicates block or tiled addressing mode. The format bit (FORMAT) can indicate the pixel format or compressed block type of the texture data. The alignment bit (ALIGN) can define the alignment boundary of each row or block. The tiling mode bit (SWZ) can distinguish between sequential tiling and Z-curve tiling modes. This embodiment does not impose special limitations on the composition of the bit fields of the storage layout flag.

[0161] The memory layout flag can be quickly determined by the hardware parser during the instruction reception phase, triggering different addressing paths. For example, during the instruction reception phase, the hardware parser can quickly decode the memory layout flag, write each bit into the status register of the texture address generation sub-cell, and automatically select either a linear addressing path or a block addressing path based on the value of the mode selection bit L_MODE. When the mode selection bit L_MODE is 0, the hardware parser outputs the path selection signal "PATH_LIN", triggering the address calculation logic of the linear addressing pipeline; when the mode selection bit L_MODE is 1, it outputs the path selection signal "PATH_TILE", starts the block addressing pipeline, and loads the corresponding block parameters (BLK_W, BLK_H, SWZ, ALIGN, etc.). The path selection signal can switch paths via an internal multiplexing control circuit (MUX), allowing subsequent address calculation units to select different calculation paths within the same pipeline framework. If a change in the flag bit is detected (e.g., resource switching or mipmap layer switching), the hardware parser re-triggers the path selection logic during the instruction scheduling phase to ensure that subsequent instructions use the same addressing path as the current resource. Furthermore, during the dynamic switching between linear addressing mode and block addressing mode, the texture address generation subunit can be scheduled based on instruction priority and cache status to avoid performance degradation caused by frequent switching.

[0162] By dynamically selecting linear addressing mode or block addressing mode based on state information, the addressing strategy can be optimized according to the texture data layout, achieving fast linear access in normal scenarios and improving cache hit rate and memory bandwidth utilization in complex compression scenarios.

[0163] Figure 4 The illustration schematically shows a process diagram of initiating a separate texture loading pipeline in a texture processing unit to load texture data according to some embodiments of the present disclosure.

[0164] refer to Figure 4 As shown, Figure 4 The diagram illustrates the processing pipeline for texture loading and texture sampling instructions in the texture processing unit of this embodiment. For example, the texture processing unit can be a TPU (Texture Processing Unit), where the thick lines represent the texture loading pipeline for texture loading instructions. Texture loading instructions from the unified shading cluster can be input to the texture address generation subunit. For example, the texture address generation subunit can be a TAG (Texture Addressing Generator). When the texture address generation subunit determines that the scheduling instruction is a texture loading instruction, it initiates a texture loading pipeline independent of the texture sampling hardware pipeline, as shown by the thick lines in the diagram. The texture address generation subunit can parse the texture coordinates and texture state information in the texture loading instruction. For example, the texture address generation subunit can be a TDD (Texture Data Decompress) subunit, which uses a virtual address calculation circuit to perform atomic address calculation on the texture coordinates and transmits the calculated virtual memory address to the L1 cache unit for data request after address unification. Simultaneously, it distributes the texture state information to the texture data decompression subunit and the texture filtering subunit. For example, the texture filtering subunit can be a TF (Texture Filter).

[0165] The texture data returned by the first-level cache unit (L1) enters the texture data decompression subunit. The texture data decompression subunit consists of a decompression and decoding circuit and an internal data buffer circuit FIFO. It is used to perform hardware decompression processing on compressed texture data and perform boundary checks and direct transmission on uncompressed texture data, thereby outputting the decompressed texture data.

[0166] The decompressed texture data is transmitted to the texture filtering subunit via a data path. The texture filtering subunit includes a texture loading instruction queue, a texture sampling instruction queue, a filter interpolation calculation module (Filter), and a format conversion circuit (Format Convert). The texture loading instruction queue buffers texture coordinates and texture state information from the texture data decompression subunit. Depending on the type of texture loading and sampling instructions, the filter interpolation calculation module can be bypassed, and the data can directly enter the format conversion circuit to reduce latency and improve instruction execution efficiency. The format conversion circuit, based on the texture state information, performs data type conversion, color channel rearrangement, and bit width expansion on the input decompressed texture data, ensuring that the converted texture data conforms to the input requirements of the unified shading cluster.

[0167] In the above process, the texture loading pipeline and the texture sampling pipeline can share resources at the hardware level, such as sharing address calculation circuits, data buffer circuits, and format conversion circuits. Furthermore, the timing of loading and sampling instructions is separated through hardware control registers to avoid instruction conflicts and data contention. Finally, the format-converted texture data is output to the unified shading cluster for subsequent pixel shading and graphics rendering tasks.

[0168] It should be noted that although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0169] Furthermore, embodiments of this disclosure also provide a texture processing unit for a graphics processor, which can be disposed in the graphics processor, see reference. Figure 5 As shown, the texture processing unit 500 for a graphics processor may include a texture address generation subunit 510, a texture data decompression subunit 520, and a texture filtering subunit 530. Wherein:

[0170] The texture address generation subunit 510 can be used to parse the texture loading instructions issued by the unified shader cluster in the graphics processor, calculate the virtual memory address based on the texture coordinates and texture state information in the texture loading instructions, and initiate a texture data loading request to the first-level cache unit based on the virtual memory address.

[0171] The texture data decompression subunit 520 can be electrically connected to the texture address generation subunit and the first-level cache unit, and is used to decompress the texture data returned by the first-level cache unit to obtain the decompressed texture data;

[0172] The texture filtering subunit 530 can be electrically connected to the texture address generation subunit and the texture data decompression subunit to perform format conversion on the decompressed texture data and return the converted texture data to the unified shading cluster.

[0173] The texture address generation subunit 510, texture data decompression subunit 520, and texture filtering subunit 530 in this embodiment have been described in the texture loading method for a graphics processor in this embodiment, and will not be repeated here. By dividing the texture processing unit into three subunits—address generation, data decompression, and filtering—and cooperating in a pipelined manner, the entire chain from instruction parsing to data format conversion can be completed internally in the hardware, shortening the texture access path and improving the overall texture processing throughput.

[0174] In an example embodiment of this disclosure, reference is made to Figure 6 As shown, the texture address generation subunit 510 may include:

[0175] The scheduling interface circuit 511 is used to receive scheduling instructions from the unified shading cluster, the scheduling instructions including the texture loading instruction and the texture sampling instruction, and to start an independent texture loading pipeline when the scheduling instruction is detected to be the texture loading instruction;

[0176] Address calculation circuit 512 is used to calculate virtual storage address based on texture coordinates and texture state information in the texture loading instruction;

[0177] The distribution circuit 513 is used to distribute the texture state information to the texture data decompression subunit and the texture filtering subunit.

[0178] The scheduling interface circuit is a hardware logic module responsible for interacting with the unified shading cluster, identifying and transmitting texture loading instructions. It can read and determine the instruction type of texture loading and texture sampling instructions issued by the unified shading cluster via a high-speed bus interface or instruction buffer queue. For example, in one feasible implementation, the scheduling interface circuit can have a built-in instruction decoder to parse instruction fields such as texture coordinates, mipmap levels, addressing modes, and texture state information; it can also be configured with a priority arbitrator to schedule the execution of texture loading instructions based on task priority or data dependencies in concurrent instruction scenarios. When a texture loading instruction is detected, the scheduling interface circuit can issue a start signal to trigger the operation of an independent texture loading pipeline.

[0179] The address calculation circuit is a hardware module used to map logical texture coordinates and state parameters to the virtual address of the target texture pixel in video memory. The address calculation circuit can perform mathematical transformations and offset operations on the coordinate parameters provided in the texture loading instruction based on the storage mode (such as linear addressing mode or block addressing mode), texture dimension, and pixel format described in the texture state information. For example, a multi-stage pipeline can be set up inside the address calculation circuit. The first stage normalizes the texture coordinates; the second stage calculates the row and column offsets based on the texture width, height, and number of channels; and the third stage combines the texture state information (such as mipmap offset values) to generate the complete virtual memory address. To improve computational efficiency, a hardware lookup table can be used to cache commonly used address offset values ​​to reduce the overhead of real-time computation. Alternatively, configurable addressing logic can be used, dynamically adjusting the addressing algorithm through microcode to be compatible with various compressed texture formats and different API interface requirements. This embodiment does not specifically limit the addressing method used by the address calculation circuit to implement the virtual memory address.

[0180] The distribution circuit is a hardware control unit used to pass the texture state parameters parsed during the address calculation stage to subsequent processing modules. The distribution circuit can use a hardware bus or point-to-point signal path to synchronously broadcast texture state information to the texture data decompression subunit and texture filtering subunit to ensure that subsequent data processing is consistent with the loading instruction parameters.

[0181] By coordinating the scheduling interface circuit, address calculation circuit, and distribution circuit, the texture address generation subunit can complete the entire hardware acceleration process from instruction reception to data addressing and status distribution, effectively improving the execution speed of texture loading instructions and the stability of the data path.

[0182] In an example embodiment of this disclosure, reference is made to Figure 7 As shown, the texture data decompression subunit may include:

[0183] The data buffer circuit 521 is used to receive texture data returned by the first-level buffer unit;

[0184] The decompression and decoding circuit 522 is used to perform decompression operations on texture data, output the decompressed texture data, and transmit the decompressed texture data to the texture filtering subunit.

[0185] Among them, the data buffer circuit refers to the hardware storage structure used for data transfer and decompression preprocessing. The data buffer circuit can queue data blocks in an orderly manner through high-speed buffer registers and FIFO queues to ensure that decompression can continuously receive texture data without pipeline blockage caused by uneven texture data reading.

[0186] During the decompression of texture data, the data buffer circuit can transfer the stored texture data blocks to the decompression / decoding circuit. The decompression / decoding circuit is a hardware-implemented decoding circuit module that can expand the texture data within the compressed block into the original pixel matrix according to a specific compression algorithm (such as BCn format, ETC format, or ASTC format). In some optional implementations, to improve decoding speed, parallel computing units can be used to process multiple pixel blocks simultaneously, or single-cycle multi-pixel decompression can be achieved through a SIMD (Single Instruction Multiple Data) architecture. After decompression, the data buffer circuit can transfer the decompressed texture data to the texture filtering subunit for subsequent format conversion.

[0187] Through the collaborative decompression operation of the data caching circuit and the decompression / decoding circuit, the texture data decompression subunit can achieve flexible format compatibility while ensuring high-speed and stable decoding, providing accurate and complete texture data input for the subsequent format conversion of the texture filtering subunit and the rendering of the unified shading cluster.

[0188] In an example embodiment of this disclosure, reference is made to Figure 8 As shown, the texture filtering subunit may include:

[0189] The texture loading queue buffer circuit 531 is used to create a texture loading queue when starting an independent texture loading pipeline. The texture loading queue is used to receive texture state information.

[0190] The format conversion circuit 532 is used to receive the texture status information transmitted by the texture loading queue buffer circuit and the decompressed texture data transmitted by the texture data decompression subunit, and perform data type conversion on the decompressed texture data according to the texture status information to obtain the converted texture data.

[0191] The output interface circuit 533 is used to output the converted texture data to the unified shader cluster.

[0192] The texture filtering subunit also includes a filter interpolation calculation circuit 534. The texture loading pipeline is used to bypass the filter interpolation calculation circuit 534 and directly input the texture state information and the decompressed texture data to the format conversion circuit to perform data type conversion.

[0193] The texture loading queue buffer circuit is a hardware cache structure specifically designed to store and schedule texture loading status parameters and related control information. When the loading pipeline starts, it sequentially writes the texture status information parsed by the texture address generation subunit into the texture loading queue, providing precise control instructions for format conversion operations. For example, the texture loading queue buffer circuit can employ a FIFO queue structure to queue the texture status information according to the instruction order; the hardware clock signal drives the reading of each texture status information entry to match the execution cycle of the format conversion circuit.

[0194] During the format conversion stage, the format conversion circuit receives texture state information from the texture loading queue buffer circuit and decompressed texture data from the texture data decompression subunit. Based on the texture state information, it performs data type conversion on the decompressed texture data. The format conversion circuit is a circuit module that uses hardware logic to adjust the arrangement, bit width, and color space of texture data into a standard format that can be directly processed by a unified shading cluster. According to the format description in the texture state information, the format conversion circuit can convert compressed or specifically arranged pixel data into the target format through operations such as shifting, channel rearrangement, color channel expansion, and precision conversion.

[0195] During the data transmission phase, the output interface circuit can be used to output the converted texture data to the unified shader cluster. The output interface circuit refers to the hardware module responsible for completing the final transmission of texture data. After the format conversion is completed, it can write data blocks to the USC's input buffer via a high-bandwidth data bus or a dedicated DMA path.

[0196] The filtering interpolation calculation circuit can be used to implement bilinear or trilinear interpolation calculations in the traditional texture sampling mode. However, in the execution mode of the texture loading pipeline, the filtering interpolation calculation circuit can be bypassed, and the texture state information and decompressed texture data can be directly input to the format conversion circuit to reduce the latency caused by irrelevant interpolation processing.

[0197] Through the coordinated operation of the texture loading queue buffer circuit, format conversion circuit, and output interface circuit, the texture filtering subunit can flexibly schedule data paths under different instruction modes, realize a texture loading pipeline that bypasses the filtering interpolation calculation circuit, and ensure that the converted texture data is delivered to the unified shading cluster in the correct format, at high speed and with low latency, providing strong support for the efficient execution of shading rendering.

[0198] In one example embodiment of this disclosure, the texture address generation subunit initiates a texture loading pipeline independent of the texture sampling instructions, and the texture loading pipeline reuses the hardware pipeline of the texture sampling instructions. The hardware pipeline reuse of the texture sampling instructions includes:

[0199] The texture loading pipeline has a shared texture address generation subunit for processing the address calculation circuit of the texture sampling instruction; a shared texture data decompression subunit for processing the texture sampling instruction; and a shared texture filtering subunit for processing the format conversion circuit of the texture sampling instruction. The texture loading instruction and the texture sampling instruction are processed separately through hardware control registers.

[0200] The reuse of the hardware pipeline for texture sampling instructions in this embodiment has already been described in detail in the embodiment of the texture loading method, and will not be repeated here. By reusing the hardware resources of sampling instructions through the texture loading pipeline and separating the timing control in the control register, interference-free instruction execution is achieved under the condition of hardware resource sharing. This reduces resource waste while maintaining the efficiency and reliability of texture loading and sampling operations.

[0201] It should be noted that although several modules or units for the texture processing unit of the graphics processor have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0202] Furthermore, an embodiment of this disclosure also provides a graphics processor, with reference to... Figure 9 As shown, the graphics processor 600 may include, for example: Figures 5 to 8 The texture processing unit 500 and the uniform shading cluster 610 are shown. The uniform shading cluster 610 can be used to issue texture loading instructions to the texture processing unit 500, so that the texture processing unit 500 can parse and execute the texture loading instructions.

[0203] Furthermore, in an exemplary embodiment of this disclosure, an electronic device capable of implementing the texture loading method for a graphics processor described above is also provided.

[0204] Those skilled in the art will understand that various aspects of this disclosure can be implemented as a system, method, or program product. Therefore, various aspects of this disclosure can be embodied in the following forms: a completely hardware embodiment, a completely software embodiment (including firmware, microcode, etc.), or an embodiment combining hardware and software aspects, collectively referred to herein as a "circuit," "module," or "system."

[0205] The following reference Figure 10 To describe an electronic device 900 according to such an embodiment of the present disclosure. Figure 10The electronic device 900 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0206] like Figure 10 As shown, the electronic device 900 is presented in the form of a general-purpose computing device. The components of the electronic device 900 may include, but are not limited to: at least one processing unit 910, at least one storage unit 920, a bus 930 connecting different system components (including storage unit 920 and processing unit 910), and a display unit 940.

[0207] The storage unit stores program code that can be executed by the processing unit 910, causing the processing unit 910 to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure. For example, the processing unit 910 can perform actions such as... Figure 1 In step S110, texture loading instructions are uniformly allocated to the texture processing unit for execution, and the texture loading instructions include texture cache loading instructions; in step S120, the texture processing unit parses and executes the texture loading instructions; wherein, the texture state information of the texture loading instructions is obtained by the hardware parsing of the texture processing unit, and the texture loading instructions complete address calculation and data reading in an independent texture loading pipeline, which is started in the texture processing unit.

[0208] Storage unit 920 may include readable media in the form of volatile storage units, such as random access memory (RAM) 921 and / or cache memory (Cache) 922, and may further include read-only memory (ROM) 923.

[0209] Storage unit 920 may also include a program / utility 924 having a set (at least one) program module 925, such program module 925 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0210] Bus 930 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0211] Electronic device 900 can also communicate with one or more external devices 970 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 900, and / or with any device that enables electronic device 900 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 950. Furthermore, electronic device 900 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 960. As shown, network adapter 960 communicates with other modules of electronic device 900 via bus 930. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 900, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0212] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0213] In exemplary embodiments of this disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the methods described above is stored. In some possible embodiments, various aspects of this disclosure may also be implemented as a program product including program code that, when the program product is run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.

[0214] refer to Figure 11 As shown, a program product 1100 for implementing the texture loading method for a graphics processor described above, according to an embodiment of the present disclosure, is illustrated. This product may be a portable compact disc read-only memory (CD-ROM) and includes program code, and may run on a terminal device, such as a personal computer. However, the program product of the present disclosure is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0215] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0216] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0217] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0218] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0219] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of this disclosure and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0220] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0221] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0222] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for texture loading for a graphics processor, the method comprising: The graphics processor comprises a texture processing unit, and the method comprises: unifying distribution of a texture loading instruction to execution of the texture processing unit, the texture loading instruction comprising a texture cache loading instruction; resolving and executing the texture loading instruction by the texture processing unit; wherein the texture processing unit comprises a texture address generation subunit, a texture data decompression subunit and a texture filtering subunit, texture state information of the texture loading instruction is resolved by the texture processing unit hardware, and the texture loading instruction is sequentially completed in an independent texture loading pipeline started by the texture address generation subunit, the texture data decompression subunit and the texture filtering subunit in cooperation, in address calculation, data decompression and format conversion.

2. The texture loading method of claim 1, wherein, The resolving and executing the texture loading instruction by the texture processing unit comprises: resolving texture state information in the texture loading instruction by the texture address generation subunit and calculating a virtual storage address, and initiating a texture data loading request to a level cache unit according to the virtual storage address; performing decompression on texture data returned by the level cache unit by the texture data decompression subunit to obtain decompressed texture data; performing format conversion on the decompressed texture data by the texture filtering subunit and returning converted texture data to a unified shading cluster.

3. The texture loading method of claim 2, wherein, The resolving texture state information in the texture loading instruction by the texture address generation subunit and calculating a virtual storage address comprises: receiving a scheduling instruction issued from the unified shading cluster, the scheduling instruction comprising the texture loading instruction and a texture sampling instruction; in response to detecting that the scheduling instruction is the texture loading instruction, starting an independent texture loading pipeline; resolving texture coordinates and texture state information in the texture loading instruction, and calculating a virtual storage address of the texture based on the texture coordinates; and distributing the texture state information to the texture data decompression subunit and the texture filtering subunit.

4. The texture loading method of claim 2, wherein, The performing decompression on texture data returned by the level cache unit by the texture data decompression subunit to obtain decompressed texture data comprises: receiving texture data returned by the level cache unit; if the texture data is in a compressed format, performing a decompression operation to obtain decompressed texture data, and outputting the decompressed texture data to the texture filtering subunit.

5. The texture loading method of claim 2, wherein, The performing format conversion on the decompressed texture data by the texture filtering subunit comprises: receiving the decompressed texture data and the texture state information issued by the texture address generation subunit; directly inputting the texture state information and the decompressed texture data into a format conversion circuit to perform data type conversion to obtain converted texture data; outputting the converted texture data to the unified shading cluster.

6. The texture loading method of claim 5, wherein, The directly inputting the decompressed texture data into a format conversion circuit to perform data type conversion comprises: The texture filtering subunit creates a texture loading queue for receiving the texture state information and transmitting the texture state information to the format conversion circuit when starting an independent texture loading pipeline; The texture loading pipeline is used to bypass the filter interpolation calculation circuit in the texture filtering subunit and input the texture state information and the decompressed texture data to the format conversion circuit to perform data type conversion.

7. The texture loading method of claim 3, wherein, The texture address generation subunit starts the texture loading pipeline to reuse the hardware pipeline of the texture sampling instruction.

8. The texture loading method of claim 7, wherein, The reuse includes: The address calculation circuit of the shared texture address generation subunit processes the address calculation circuit of the texture sampling instruction; The data buffer circuit of the shared texture data decompression subunit processes the data buffer circuit of the texture sampling instruction; The format conversion circuit of the shared texture filtering subunit processes the format conversion circuit of the texture sampling instruction; The texture loading instruction and the texture sampling instruction are separated in time by a hardware control register.

9. The texture loading method of claim 1, wherein, The texture loading method for the graphics processor supports unbound texture resources.

10. The texture loading method of claim 2, wherein, When calculating the virtual storage address, the texture address generation subunit selects a linear addressing mode or a block addressing mode according to the texture state information in the texture loading instruction.

11. A texture processing unit for a graphics processor, the texture processing unit comprising: It includes: A texture address generation subunit is configured to parse a texture loading instruction issued by a unified shading cluster in a graphics processor, calculate a virtual storage address according to texture coordinates and texture state information in the texture loading instruction, and initiate a texture data loading request to a level one cache unit according to the virtual storage address. The texture address generation subunit includes a scheduling interface circuit configured to receive a scheduling instruction from the unified shading cluster, the scheduling instruction including the texture loading instruction and a texture sampling instruction, and start an independent texture loading pipeline when detecting that the scheduling instruction is the texture loading instruction; A texture data decompression subunit is electrically connected with the texture address generation subunit and the level one cache unit, configured to perform decompression on texture data returned by the level one cache unit to obtain decompressed texture data; A texture filtering subunit is electrically connected with the texture address generation subunit and the texture data decompression subunit, configured to perform format conversion on the decompressed texture data and return the converted texture data to the unified shading cluster. The texture filtering subunit includes a texture loading queue buffer circuit configured to create a texture loading queue when starting an independent texture loading pipeline, the texture loading queue being configured to receive the texture state information.

12. The texture processing unit of claim 11, wherein, The texture address generation subunit includes: An address calculation circuit configured to calculate a virtual storage address based on texture coordinates and texture state information in the texture loading instruction; A distribution circuit configured to distribute the texture state information to the texture data decompression subunit and the texture filtering subunit.

13. The texture processing unit of claim 11, wherein, The texture data decompression subunit includes: A data buffer circuit configured to receive texture data returned by the level one cache unit; A decompression decoding circuit is configured to perform a decompression operation on the texture data, output decompressed texture data, and transmit the decompressed texture data to the texture filtering subunit.

14. The texture processing unit of claim 11, wherein, The texture filtering subunit includes: A format conversion circuit is configured to receive the texture state information transmitted by the texture loading queue buffer circuit and the decompressed texture data transmitted by the texture data decompression subunit, perform a data type conversion on the decompressed texture data according to the texture state information, and obtain converted texture data. An output interface circuit is configured to output the converted texture data to the unified shading cluster. The texture filtering subunit further includes a filtering interpolation calculation circuit, and the texture loading pipeline is configured to bypass the filtering interpolation calculation circuit and directly input the texture state information and the decompressed texture data to the format conversion circuit to perform the data type conversion.

15. The texture processing unit of claim 12, wherein, The texture address generation subunit starts a texture loading pipeline independent of the texture sampling instruction, and the texture loading pipeline reuses a hardware pipeline of the texture sampling instruction, and the reuse includes: The texture loading pipeline shares an address calculation circuit of the texture address generation subunit to process the texture sampling instruction. The texture loading pipeline shares a data buffer circuit of the texture data decompression subunit to process the texture sampling instruction. The texture loading pipeline shares a format conversion circuit of the texture filtering subunit to process the texture sampling instruction. The texture loading instruction and the texture sampling instruction are separated in a hardware control register processing timing.

16. A graphics processor, comprising: The graphics processing unit includes: The texture processing unit according to any one of claims 11 to 15; A unified shading cluster configured to issue a texture loading instruction to the texture processing unit, so that the texture loading instruction is parsed and executed by the texture processing unit.

17. An electronic device, comprising: The graphics processing unit includes: The graphics processing unit according to claim 16; and A memory having computer readable instructions stored thereon, the computer readable instructions being executed by the graphics processing unit to implement the texture loading method for a graphics processing unit according to any one of claims 1 to 10. A computer program stored on a computer readable medium, the computer program being executed by the graphics processing unit according to claim 16 to implement the texture loading method for a graphics processing unit according to any one of claims 1 to 10.

18. A computer-readable storage medium, characterized in that, ​

Images