Processing method and device for rendering depth data and related equipment

Abstract

The invention provides a rendering depth data processing method and device and related equipment. The method comprises the following steps: loading rendering depth data from a first storage space; the rendering depth data is represented through a preset format, and the preset format is used for defining a storage mode of an initial depth value of the first bit number and a template value of the second bit number; performing a depth test according to an initial depth value in the rendering depth data, and obtaining a target depth value according to a depth test result; generating target depth data corresponding to the target depth value; the target depth data comprises a target depth value and a target placeholder, the target depth value is a first bit number, and the target placeholder is a second bit number; and packaging the target depth data into a data packet, and transmitting the packaged data packet to the second storage space through the data bus. According to the mode, the bit width of the preset format is accurately matched, so that the bus bandwidth waste caused by misalignment of the data bit width is eliminated.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method, apparatus and related equipment for processing rendering depth data. Background Technology

[0002] In computer graphics rendering pipelines, rendering depth data, also known as Z-axis data or buffer depth data, is typically used to characterize the vertical distance of each element to be rendered in a scene from the virtual camera's perspective. This value does not directly determine the color of the element being rendered, but rather the occlusion relationship between objects in the 3D scene.

[0003] During rendering, a depth value is typically calculated for each fragment to be rendered, usually ranging from 0.0 for the Near Clipping Plane to 1.0 for the Far Clipping Plane. The Graphics Processing Unit (GPU) uses a crucial step called Depth Test to compare the calculated depth value of the current fragment with the corresponding depth value stored in the Z-Buffer. Test rules (such as "nearer passes") ensure that the framebuffer and depth buffer are only updated if the current fragment is located before any existing fragment. This mechanism is fundamental to the real-time, accurate rendering of complex 3D scenes and efficiently solves the problem of hidden face elimination.

[0004] Therefore, it is evident that a solution capable of efficiently processing rendering depth data is urgently needed in the image rendering process. Summary of the Invention

[0005] This disclosure provides a method, apparatus, and related equipment for processing rendering depth data.

[0006] In a first aspect, this disclosure provides a method for processing rendering depth data, the method comprising:

[0007] The rendering depth data is loaded from the first storage space; the rendering depth data is characterized by a preset format, which is used to define the storage method of the initial depth value of the first bit length and the template value of the second bit length.

[0008] A depth test is performed based on the initial depth value in the rendered depth data, and the target depth value is obtained based on the depth test result.

[0009] Generate target depth data corresponding to the target depth value; the target depth data includes: the target depth value and a target placeholder, wherein the target depth value is the first number of bits and the target placeholder is the second number of bits;

[0010] The target depth data is encapsulated into a data packet, and the encapsulated data packet is transmitted to the second storage space via a data bus.

[0011] Secondly, this disclosure provides a processing apparatus for rendering depth data, the apparatus comprising:

[0012] A loading module is adapted to load the rendering depth data from a first storage space; the rendering depth data is characterized by a preset format, which is used to define the storage method of the initial depth value of the first bit length and the template value of the second bit length.

[0013] The testing module is adapted to perform a depth test based on the initial depth value in the rendered depth data, and to obtain the target depth value based on the depth test results.

[0014] The generation module is adapted to generate target depth data corresponding to the target depth value; the target depth data includes: the target depth value and a target placeholder, wherein the target depth value is the first number of bits and the target placeholder is the second number of bits;

[0015] The encapsulation module is adapted to encapsulate the target depth data into a data packet, so as to transmit the encapsulated data packet to the second storage space via a data bus.

[0016] Thirdly, this disclosure provides an image rendering system, including: the above-mentioned rendering depth data processing device.

[0017] Fourthly, this disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the method as described above.

[0018] Fifthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described method.

[0019] In a sixth aspect, this disclosure provides a computer program product comprising computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device performs the method described above.

[0020] In the rendering depth data processing method provided in this disclosure, when the rendering depth data is represented by a preset format, and the preset format defines the storage method of the initial depth value of the first bit length and the template value of the second bit length, in order to avoid the problem of low transmission efficiency caused by the mixing of depth value and template value, the target depth value obtained after depth testing is filled, and target placeholders are used to ensure that the target depth data to be transmitted is filled to an aligned and complete bit width (e.g., the same as the bit width defined in the preset format). Therefore, the target depth data in this disclosure has at least the following characteristics: on the one hand, the data bit width of the target depth data is the same as the total number of bit widths defined in the preset format, that is, the data bit width of the target depth data is equal to the sum of the first bit length and the second bit length defined in the preset format, thus ensuring compatibility with the preset format; on the other hand, the other data in the target depth data besides the target depth value are target placeholders, and these target placeholders are usually considered valid data during the data packet encapsulation process, thus not affecting the data packet encapsulation process. As can be seen, this method eliminates the bus bandwidth waste caused by data bit width misalignment by accurately matching the bit width of the preset format. Compared with directly transmitting the unaligned target depth value, it maximizes the bandwidth utilization of each transmission, reduces the overall transmission latency, and thus improves the overall efficiency of data write-back in the rendering pipeline.

[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0022] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed description of exemplary embodiments with reference to the accompanying drawings, in which:

[0023] Figure 1 A flowchart illustrating a method for processing rendering depth data provided in this embodiment of the disclosure;

[0024] Figure 2 A pixel surface based on the D24S8 format is shown;

[0025] Figure 3 This diagram illustrates the packet encapsulation in the D24S8 format.

[0026] Figure 4 A schematic diagram of a deep surface is shown;

[0027] Figure 5 A schematic diagram of the template surface is shown;

[0028] Figure 6 This diagram illustrates the process of loading depth data from GPU memory to the local depth testing module.

[0029] Figure 7 This diagram illustrates the process of writing depth data from the depth testing module to system memory.

[0030] Figure 8 A block diagram of a rendering depth data processing apparatus provided in an embodiment of this disclosure;

[0031] Figure 9 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0032] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0033] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0034] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0035] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0036] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0037] The method for processing rendering depth data according to embodiments of this disclosure can be executed by an electronic device such as a terminal device or a server. The terminal device can be an in-vehicle device, user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. The method can be implemented by a processor calling computer-readable program instructions stored in memory. Alternatively, the method can be executed by a server.

[0038] In computer graphics, especially in real-time rendering, depth testing is a key technique for ensuring the correct occlusion relationships of objects in a scene. Depth data and stencil data are typically stored in the local memory (video memory) of the graphics processing unit (GPU) in a fixed interleaved format (e.g., the widely adopted D24S8 format, where 24-bit depth values ​​and 8-bit stencil values ​​are interleaved).

[0039] In traditional interleaved memory formats such as D24S8, depth values ​​and template values ​​are interleaved. When only depth data needs to be written to system memory, the template value is considered invalid due to the interleaved arrangement. Consequently, the bus controller will split the continuous depth data into numerous small data packets for transmission because of the presence of invalid template bytes, resulting in low transmission efficiency and severely insufficient utilization of effective bandwidth. To address this issue, this application proposes an improved method: when writing depth data to system memory, the initial depth value is extracted, and placeholders of the same bit length are set according to the bit length of the template value. This ensures that the total bit length of the depth data to be transmitted is the same as that of interleaved memory formats such as D24S8, and only placeholders considered as valid bytes are included, excluding template values ​​considered as invalid bytes. This avoids the packet splitting problem caused by invalid bytes and improves transmission efficiency.

[0040] Figure 1 A flowchart illustrating a method for processing rendering depth data according to an embodiment of this disclosure. (Refer to...) Figure 1 The method includes:

[0041] Step S110: Load rendering depth data from the first storage space; the rendering depth data is represented by a preset format, which is used to define the storage method of the initial depth value of the first bit length and the template value of the second bit length.

[0042] The first storage space refers to the physical or logical storage area used to store rendering depth data. In graphics processing, this typically refers to the graphics processor's local memory, i.e., video memory, which has a much higher access speed than system memory and is crucial for the efficient operation of the real-time rendering pipeline. In this application, rendering depth information can broadly refer to all data related to depth testing in the graphics rendering pipeline, including but not limited to depth values ​​read from the depth buffer and new depth values ​​to be written after depth testing. Therefore, in the 3D graphics rendering process, rendering depth data can be a set of depth information used to determine pixel visibility. Its core function is to solve the hidden surface elimination problem, ensuring that surfaces closer to the observer (such as a virtual camera) can correctly occlude distant surfaces.

[0043] A preset format refers to a binary encoding rule predefined in hardware or a driver for arranging depth and template data in memory. It defines not only the initial depth value (first bit length) and the template value (second bit length), but also the relative positions, bit offsets, and overall byte alignment of these two data components within the same data unit. In short, the core feature of a preset format is that it defines a composite data format containing both an initial depth value and a template value, and specifies the bit length for each data component. For example, a preset format could be D24S8. D24S8 is a combined format based on a 24-bit depth and an 8-bit template. D24 represents the 24-bit depth value, and S8 represents the 8-bit template value. This combined format indicates that the depth value and template value are tightly packed within the same 32-bit data unit. Besides D24S8, preset formats can also be derived from other types of formats, such as a combined format based on an M-bit depth and an N-bit template, where M and N are natural numbers. Correspondingly, the first bit has M bits and the second bit has N bits.

[0044] The initial depth value can be the currently stored depth value read from the depth buffer before a new round of depth testing. It represents the historical depth information of the closest visible segment to the camera in the scene before the current rendering batch. The first bit of the initial depth value determines the precision range of the depth value; for example, 24 bits can provide approximately 16 million different depth levels. The stencil value can be stored in the stencil buffer, specifically as an integer value corresponding to a pixel. It is typically used to implement complex rendering effects such as masking, contour outlining, and shadow volume. The second bit of the initial depth value defines the number of states available for stencil testing; for example, 8 bits allow 256 different stencil states from 0 to 255.

[0045] This step allows you to load rendering depth data from the depth buffer in GPU memory. In practice, rendering depth data can be represented by a depth surface in GPU memory.

[0046] Optionally, the initial depth value of the first bit depth and the template value of the second bit depth can be stored in different buffers in the first storage space, so as to facilitate subsequent processing steps through the separate storage mode.

[0047] Step S120: Perform a depth test based on the initial depth value in the rendering depth data, and obtain the target depth value based on the depth test results.

[0048] Depth testing is a fixed or configurable function in the graphics rendering pipeline. Essentially, it's a comparison process that compares the depth value of the currently processed fragment with the initial depth value stored at the same pixel location in the depth buffer (i.e., the rendering depth data). The rules governing this comparison can be determined by the depth testing function. Correspondingly, the depth test result refers to the Boolean value generated by the depth test comparison operation, which can be either "pass" or "fail".

[0049] The target depth value refers to the new depth value that needs to be updated in the depth buffer after the depth test. Its specific value depends on the depth test result and the depth write status. If the test passes and depth writing is enabled, the target depth value is usually the depth value of the current fragment; if the test fails or depth writing is disabled, the target depth value remains unchanged from the initial depth value. Therefore, the target depth value can be obtained from the rendered depth data through the depth test operation.

[0050] Step S130: Generate target depth data corresponding to the target depth value; the target depth data includes: the target depth value and the target placeholder, the target depth value is the first bit length and the target placeholder is the second bit length.

[0051] In this context, the target placeholder refers to auxiliary data bits appended to the target depth value to meet specific format requirements of the data structure (such as byte alignment, fixed data packet length). It does not carry actual depth information itself, and its width can be determined by the number of bits in the second bit. The main function of the target placeholder is to fill space, ensuring the entire data unit reaches the predetermined size.

[0052] Accordingly, target depth data refers to a complete data unit that conforms to a predetermined format, consisting of the target depth value and the target placeholder. Therefore, the processing in this step ensures that the bit width of the final generated target depth data is the same as the bit width specified in the preset format, which is the sum of the first and second bits, thus ensuring that the target depth data accurately adapts to the preset format.

[0053] Furthermore, the bit width of the target placeholder contained in the target depth data is determined according to the second bit width of the template value defined in the preset format. This allows the storage format of the original interleaved storage of depth values ​​and template values ​​to be improved to storing only depth values. By using placeholder padding, it is ensured that the data bit width when storing only depth values ​​is the same as the data bit width when storing them in the original interleaved format, thus facilitating the subsequent data packet encapsulation process.

[0054] Step S140: Encapsulate the target depth data into a data packet, and transmit the encapsulated data packet to the second storage space via the data bus.

[0055] Encapsulation refers to the process of packaging target depth data according to the format required by a specific communication protocol. This process typically involves adding necessary control information, such as a header (containing the target address, data packet sequence number, etc.) and a trailer (such as a cyclic redundancy check (CRC) for error checking), before and after the data payload, forming a unit that can be transmitted independently over the transmission medium. Correspondingly, a data packet is the basic unit formed after encapsulation that can be transmitted in the network. A complete data packet usually consists of a header, a payload (i.e., target depth data), and a trailer.

[0056] A data bus is a common communication channel used to transmit data, addresses, and control signals within a computer system or between different systems. For example, a data bus can take various forms such as PCIe (Peripheral Component Interconnect), Universal Serial Bus, etc. The second storage space in this disclosure refers to the final destination of data packet transmission. It is distinct from the local cache (first storage space) used for real-time rendering calculations. It is typically a larger-capacity but relatively slower-access storage medium, such as a computer's system memory, hard disk drive, solid-state drive, or object storage service located in the cloud.

[0057] By using packet encapsulation and bus transmission, the processed target depth data can be efficiently and reliably migrated from the processing unit (such as GPU local memory) to the outermost second storage space (such as system memory or cloud storage). This ensures that depth data can flow smoothly between different computing units or storage levels, providing a foundation for subsequent large-scale data analysis, long-term archiving, or cross-device sharing.

[0058] Since the target depth data contains target placeholders, and these placeholders are usually treated as valid bytes during the encapsulation process, they do not affect the continuity of the data packets and can improve encapsulation efficiency.

[0059] Therefore, in this embodiment of the present disclosure, when the rendered depth data is represented by a preset format, and the preset format defines the storage method of the initial depth value of the first bit length and the template value of the second bit length, in order to avoid the problem of low transmission efficiency caused by the mixing of depth values ​​and template values, the target depth value obtained after the depth test is filled, and target placeholders are used to ensure that the target depth data to be transmitted is filled to an aligned and complete bit width (e.g., the same as the bit width defined in the preset format). Thus, the target depth data in this disclosure has at least the following characteristics: on the one hand, the data bit width of the target depth data is the same as the total number of bit widths defined in the preset format, that is, the data bit width of the target depth data is equal to the sum of the first bit length and the second bit length defined in the preset format, thereby ensuring compatibility with the preset format; on the other hand, the data other than the target depth value in the target depth data are target placeholders, and these target placeholders are usually considered valid data during the data packet encapsulation process, thus not affecting the data packet encapsulation process. As can be seen, this method eliminates the bus bandwidth waste caused by data bit width misalignment by accurately matching the bit width of the preset format. Compared with directly transmitting the unaligned target depth value, it maximizes the bandwidth utilization of each transmission, reduces the overall transmission latency, and thus improves the overall efficiency of data write-back in the rendering pipeline.

[0060] Furthermore, those skilled in the art can make various modifications and variations to the embodiments disclosed herein:

[0061] In the process of realizing this disclosure, the inventors discovered that the traditional interleaved storage method has at least the following drawbacks:

[0062] Traditional rendering pipelines use a fixed storage layout, which cannot be dynamically optimized according to the final use of the data (whether it is consumed inside the GPU or needs to be transferred back to system memory). As a result, in advanced rendering technologies that require high-frequency data readback, data transfer becomes the main bottleneck of system performance.

[0063] To address the aforementioned issues, before loading rendering depth data from the first storage space, the following further operations can be performed: if the current storage mode is determined to be a pre-configured split storage mode, a depth buffer is created in the first storage space; wherein the depth buffer is used to store rendering depth data, and each element in the rendering depth data includes: an initial depth value of a first number of bits, and an initial placeholder of a second number of bits. By introducing an intelligent mode determination and resource pre-allocation mechanism, dynamic optimization of the rendering depth data storage structure is achieved. For example, this disclosure can determine whether to enable the split storage mode based on application requirements (such as data readback), and accordingly, pre-create a depth buffer conforming to the mode specification in the first storage space (such as GPU memory) before the rendering process begins. This buffer organizes the depth data into regular elements containing valid depth values ​​and reserved placeholders, laying the foundation for efficient subsequent data processing and transmission.

[0064] The current storage mode refers to the configuration state in the graphics rendering pipeline used to manage the storage method of depth (and stencil) data. It is usually dynamically set by the GPU driver based on the application's API call instructions (such as resource creation flags) and the rendering context. Separate storage mode is a novel data storage mode proposed in this disclosure. In separate storage mode, depth data and stencil data are allocated to two memory regions with independent physical addresses (i.e., independent depth buffers and stencil buffers), rather than traditional interleaved storage.

[0065] In graphics processing, a depth buffer can be a two-dimensional memory region specifically used to store scene depth information. Its size is typically the same as the frame buffer, with each pixel corresponding to a depth value. In the separate storage mode proposed in this disclosure, the storage space for each element (corresponding to one pixel) in this buffer is designed to be larger than the number of bits required for the effective depth value. For example, 32 bits are allocated for a 24-bit effective depth value, with the extra 8 bits serving as initial placeholders. Initial placeholders refer to data bits reserved in the depth buffer for each pixel depth value element that do not directly store effective depth information. Their main function is to satisfy memory address alignment requirements and provide padding space for standard data packet encapsulation during subsequent data transmission.

[0066] In the above approach, by creating a depth buffer where each element contains a regular depth value and placeholders, the continuity and alignment of depth data in memory are ensured from the source. This allows the GPU to directly encapsulate large blocks of continuous depth data into standard-sized data packets (e.g., 32-bit) for transmission via the bus when subsequent readbacks are needed. This significantly reduces the number of data packets and related protocol overhead, thereby significantly improving the effective bandwidth utilization and transmission efficiency of buses such as PCIe. Furthermore, by determining the storage mode before creating the buffer, on-demand configuration of storage resources is achieved: applications do not need to pay for the additional memory overhead of separate storage in all cases; this mode is only enabled in scenarios where efficient readbacks are truly required, achieving a balance between performance and resource consumption. Moreover, by optimizing the data transmission path, this approach reduces communication latency between the GPU and system memory. For applications that require real-time processing of depth data (such as high-frame-rate games and VR / AR), this effectively reduces end-to-end latency and improves system responsiveness and smoothness.

[0067] Optionally, if the current storage mode is determined to be a pre-configured separate storage mode, a template buffer, separate from the depth buffer, is further created in the first storage space. The template buffer stores template data, and each element in the template data includes a template value with a second bit depth. By creating a dedicated template buffer in the first storage space, physically isolated from the depth buffer, independent storage and management of template data within its own contiguous memory region is achieved. This ensures that depth values ​​and template values ​​are no longer intertwined in the same memory block, but rather each has its own independent, aligned data path, laying the foundation for efficient parallel processing of the two types of data.

[0068] In graphics rendering, the stencil buffer can be a two-dimensional memory area specifically used to store mask information required for stencil testing. Stencil testing can be a pixel-based operation used to control whether specific areas on the rendering target surface (such as a screen or texture) are drawn, thereby achieving advanced visual effects such as mirrors, contours, and shadow volumes. In the separate storage mode of this disclosure, the stencil buffer can be a memory block whose physical address is completely independent of the depth buffer. Stencil data refers to the data set stored in the stencil buffer that corresponds one-to-one with screen pixels. The stencil value of each element (corresponding to one pixel) serves as a mask or marker, used to determine whether the pixel participates in drawing or how it is processed during subsequent rendering. The stencil value refers to the specific numerical value of each element in the stencil data, and its bit width is defined by the number of bits in the second bit (for example, a common 8-bit stencil value can represent 256 states from 0 to 255). The stencil value itself does not directly represent color or depth, but rather serves as a control signal, used to determine whether a pixel is drawn by performing calculations with a preset reference value and a comparison function.

[0069] In the above approach, the introduction of an independent template buffer creation operation can solve many problems existing in traditional interleaved storage modes (such as D24S8) in specific application scenarios:

[0070] (1) In interleaved storage, when the rendering pipeline only needs to perform stencil testing (but not depth testing), the hardware has to load the entire interleaved data block (including depth values) into the cache and then extract the stencil values, thus wasting memory bandwidth and cache space. With independent storage, stencil testing can directly and efficiently access the clean stencil data block.

[0071] (2) In some advanced rendering techniques (such as GPU-based template data post-processing and dynamic template mask generation), template data needs to be treated as a processing object. However, the interleaved storage mode makes it complex and inefficient to extract a clean template data stream. By creating an independent template buffer, template data can be conveniently bound as a shader resource, just like color textures, for sampling, calculation, or reading back into system memory, thus expanding the application methods of template data.

[0072] (3) In the interleaved format, the number of bits of the template value is fixed (e.g., the template is 8 bits in the D24S8 format). The independent storage mode allows the application to flexibly allocate appropriate bit width to the template buffer as needed (e.g., using 4 bits in some simple scenarios to save memory, and using 16 bits in complex scenarios to support more states), without being bound by the fixed format.

[0073] Therefore, the separate storage model proposed in this disclosure can achieve at least the following beneficial effects:

[0074] (1) Maximize memory access efficiency: Depth and template data are stored in contiguous memory blocks, making the GPU’s memory access pattern more regular and predictable, which is conducive to the hardware prefetching mechanism to play its role, reducing memory access latency, thereby improving rendering performance, especially under high-resolution rendering.

[0075] (2) Achieve parallel processing capability: Due to the physical separation of data, the GPU rendering pipeline can perform more in-depth optimization of depth testing and template testing. For example, under a specific architecture, the two tests can be processed in a more parallel manner, further shortening the overall pixel processing time.

[0076] (3) Enhanced rendering capabilities: An independent stencil buffer provides underlying support for implementing more complex and efficient stencil-based effects. For example, when implementing shadow volume effects, it is necessary to frequently increment and decrement the stencil value. An independent buffer allows these operations to be completed faster and more atomically. Moreover, applications can independently manage the lifecycle of depth and the stencil buffer. For example, the stencil buffer can be released only in scenes where stencil effects are not used to save video memory; or different compression or storage formats can be selected for the stencil buffer to adapt to diverse performance and quality requirements.

[0077] In one alternative implementation, the rendering depth data is loaded by: loading the rendering depth data from a depth buffer; and for any element in the rendering depth data, extracting the initial depth value of the first bit width contained in the element. By performing this core operation of valid information extraction, the original depth information for depth testing is accurately obtained from the depth buffer. Specifically, a complete block of rendering depth data is first loaded from the depth buffer. Then, for each data unit (element), the initial depth value defined by the valid bit width (first bit width) is accurately extracted by hardware logic, thus providing standardized input data for subsequent depth comparison. Here, an element refers to a basic storage unit in the rendering depth data, typically corresponding to a pixel position on the screen. In the separate storage mode of this disclosure, the storage space occupied by this element in memory is greater than the bit width required for the valid depth value; for example, an element may occupy 32 bits, containing a 24-bit valid depth value and an 8-bit initial placeholder. Through the data extraction operation, a bit-width-accurate initial depth value is provided for depth comparison. The extracted, well-organized depth data blocks are easier to package and transmit efficiently via buses such as PCIe, avoiding inefficient unpacking caused by data interleaving. This provides performance assurance for application scenarios that require reading depth data back into system memory.

[0078] In one optional implementation, to facilitate dynamic switching of storage modes, separate storage conditions for triggering separate storage mode can be pre-configured. Accordingly, if the received depth buffer creation request meets the preset separate storage conditions, the current storage mode is determined to be the pre-configured separate storage mode. Optionally, the preset separate storage conditions include: (1) the data format corresponding to the depth buffer creation request is a preset format, for example, the data format is D24S8 format; (2) the target depth value needs to be transmitted to the second storage space, that is: the target depth value needs to be returned to the system memory; (3) template testing is not enabled, or the data transmitted to the second storage space does not contain the template value, that is: when returning to the system memory, the template value does not need to be transmitted, and correspondingly, the template value is in an invalid state during the transmission to the system memory. Under normal circumstances, the above three conditions need to be met simultaneously.

[0079] Therefore, by comprehensively analyzing the data format of the deep buffer, its end use (whether it needs to be read back to system memory), and the rendering pipeline status (whether template testing is used), the separate storage condition ensures that the separate storage mode proposed in this disclosure is only triggered in scenarios that can bring significant performance improvements, thereby achieving a balance between storage resource overhead and data transmission efficiency.

[0080] The depth buffer creation request is initiated by the application through the graphics API, requesting the GPU driver to allocate a specific resource in video memory for storing depth information. This request typically includes key descriptors such as the resource's format, size, and purpose. Preset separate storage conditions can be a set of logical judgment rules preset within the driver. The driver will only decide to enable separate storage mode when the depth buffer creation request simultaneously meets all the conditions in this set. Typically, the second storage space is system memory, relative to the GPU's local video memory (the first storage space). Data needs to be transferred to the second storage space via buses such as PCIe for access by the CPU or other heterogeneous processors. Enabling stencil testing means that the stencil testing phase is activated in the graphics rendering pipeline, implying that the rendering process requires not only depth information but also stencil values ​​to perform complex effects such as contour outlining and reflection area definition.

[0081] In one alternative implementation, the GPU can be notified to switch to detached memory mode by configuring register states. Specifically, if the received depth buffer creation request meets preset detached memory conditions, the state of the preset register is configured to the preset state. Correspondingly, if the preset register state is detected to be in the preset state, the current memory mode is determined to be the pre-configured detached memory mode. In this way, the intelligent decision-making results of the software layer (such as the GPU driver) can be represented by register state bits that can be directly detected by the hardware circuitry, thereby achieving efficient and decoupled instruction transmission between the driver and the hardware rendering pipeline, ensuring that detached memory mode can be accurately and timely enabled.

[0082] The preset register can be a reserved memory-mapped register with a specific function within the graphics processor's internal address space. It typically consists of several bit fields, each independently readable and writable, used to control the operating mode or state of a specific functional unit of the GPU. In this disclosure, this register can be used to control the storage strategy for depth / stencil data. The register state refers to the current value of a specific bit or bit field in the preset register. The preset state can be a specific value or bit combination predefined by the architecture, representing the activation of a separate memory mode.

[0083] In practice, a single bit can be used in the preset register to represent the storage mode. For example, when the bit is 1 (preset state), it indicates that the split storage mode is enabled; when it is 0, it indicates that the traditional interleaved mode is used. This method only requires an AND gate or a comparator to complete the state determination, without introducing additional latency and power consumption, making it suitable for mobile or embedded GPU architectures with high power consumption and timing requirements.

[0084] Alternatively, a multi-bit-width (e.g., 3-4 bits) bit field can be used in the preset register to encode the storage mode. This not only indicates the enable / disable state but also further distinguishes different sub-modes or configuration parameters. For example, it can indicate the specific bit-width combination of the depth surface and the template surface (e.g., D24S8, D32F), or specify the memory alignment. This approach provides rich configurability, allowing the driver to pass more complex configuration information through a single register write. The hardware can perform more granular resource allocation and data path control based on the encoded values, enhancing flexibility and adaptability to new formats.

[0085] In one optional implementation, the method for processing rendering depth data in this disclosure can be executed by a depth testing module included in the graphics processing unit (GPU). Furthermore, the first storage space may include: local memory space within the GPU; the second storage space may include: system memory space of the device where the GPU resides. The depth testing module is a fixed-function hardware unit within the GPU rendering pipeline specifically responsible for performing depth testing operations. Its main functions include: reading the depth value of the current pixel from the depth buffer, comparing it with the depth value of the fragment to be rendered, and determining whether to update the depth buffer or discard the fragment based on the comparison result. Local memory space refers to high-speed memory (i.e., video memory) physically located near the GPU chip or directly integrated within the GPU package. In this disclosure, the local memory space is used to store intermediate data required for real-time rendering, such as the depth buffer and stencil buffer. System memory space can be the main memory on the computer motherboard directly managed by the CPU through the memory controller. In this disclosure, the system memory space is mainly used to receive depth data read back from the GPU for subsequent processing by the CPU or other coprocessors.

[0086] In one optional implementation, when transmitting the encapsulated data packet to the second storage space, the encapsulated data packet is transmitted to the system memory space via a peripheral component interconnection protocol; wherein, the target placeholder in the target depth data and the target depth value both belong to the valid bytes. Optionally, the preset format is a combined format based on an M-bit depth and an N-bit template, where M and N are natural numbers; and the first bit is M bits and the second bit is N bits.

[0087] The Peripheral Component Interconnect Protocol (PCIe) refers to a standard high-speed serial computer expansion bus standard used to connect high-speed peripheral devices (such as graphics cards, network cards, and memory controllers) within a computer. In this disclosure, it can refer to the interface used to connect the GPU and the CPU / chipset, serving as the physical channel for data transfer from the GPU's local video memory to system memory. A valid byte refers to the portion of a data packet that carries meaningful information and is expected to be processed by the receiver, in the context of data communication and processing; the opposite is an invalid byte. Since the target placeholder and the target depth value both belong to the valid bytes, during PCIe transmission, the entire 32-bit data packet (including the 24-bit depth value and the 8-bit placeholder) is considered a complete and indivisible payload unit.

[0088] To facilitate understanding, an example is provided below to illustrate the specific implementation of the rendering depth data processing method provided in this disclosure. This example proposes a depth and stencil separation storage mode based on the D24S8 format. The GPU's depth buffer (also known as the Z-Buffer) is a crucial off-screen buffer in the graphics rendering pipeline, specifically designed to address visibility issues (determining which objects or parts of objects are visible in the final image). The data format of this depth buffer determines the storage precision and range of depth values, directly affecting rendering accuracy and potential visual artifacts (such as depth conflicts / Z-fighting).

[0089] The depth buffer primarily supports the following common data formats:

[0090] (1) 16-bit fixed-point depth (depth UNORM16)

[0091] This format is a commonly used format, especially suitable for early hardware and mobile devices. It uses 16-bit unsigned integers (ranging from 0 to 65535) to represent depth. The advantages of this format are: small memory footprint (2 bytes per pixel) and low bandwidth requirements. However, its disadvantages include at least: limited precision and a high susceptibility to depth conflicts (Z-fighting). This format is primarily suitable for memory- and bandwidth-sensitive scenarios (such as mobile devices) or scenarios with a small depth range (small distance / nearness ratio).

[0092] (2) 24-bit fixed-point depth (depth UNORM24+UINT8)

[0093] This format is currently the most mainstream depth buffer format on PC and console platforms. It typically shares a 32-bit storage unit (called D24S8 format) with an 8-bit stencil buffer. The advantages of this format are: significantly higher precision than 16-bit, effectively mitigating most depth conflict issues, and relatively reasonable memory usage (4 bytes including the stencil). However, its drawbacks include at least one: uneven precision distribution (higher precision at closer points and lower precision at farther points). This format is suitable for the vast majority of modern games and graphics applications.

[0094] (3) 32-bit floating-point depth (FP32)

[0095] This format uses standard IEEE 754 single-precision floating-point numbers (32 bits) to store depth values. Its advantages include high precision, providing accuracy far exceeding that of fixed-point numbers, and a wider dynamic range, making it better suited for reverse depth applications. However, its drawbacks include a large memory footprint (4 bytes per pixel, excluding the template), twice that of the 24-bit format (excluding template comparison), resulting in high bandwidth requirements. This format is primarily suitable for applications requiring extremely high precision (scientific visualization, CAD / CAM, etc.).

[0096] As described above, the 24-bit depth format combines high precision, low storage and bandwidth requirements, and has been widely used in graphics rendering. This is because the D24S8 format implicitly includes a layer of information: depth data and template data are tightly packed together for storage. Figure 2 This shows an 8×8 pixel surface implemented in D24S8 format, such as... Figure 2 As shown, each pixel's data storage in memory consists of 4 bytes: 3 depth bytes (i.e., ... Figure 2 Bytes 0-2) and 1 template byte (i.e. Figure 2 Byte 3 in the middle.

[0097] Normally, resources such as the depth buffer are stored in GPU local memory to allow the GPU to quickly retrieve or update relevant data to complete rendering tasks. In this method, the processed depth data from the graphics processor is directly transferred to local memory. Therefore, in this method, the GPU and local memory can directly interconnect to read and store depth data.

[0098] However, some applications require that depth buffer data be directly output to system memory after rendering for easy access later. In this latter approach, the depth data processed by the graphics processor needs to be transferred to system memory via Peripheral Component Interconnect Express (PCIe). Therefore, when the GPU interacts with system memory, the depth data processed by the GPU needs to be written to system memory via PCIe, and when the GPU needs to read this data, it also needs to load it from system memory via PCIe. PCIe is a bytemask protocol, meaning it tries to pack consecutive valid bytes together as a data packet for transmission; however, if a string of bytes contains several invalid bytes, it must be unpacked at the invalid byte locations.

[0099] Figure 3A schematic diagram of packet encapsulation in the D24S8 format is shown. For example... Figure 3 As shown, if only depth testing is enabled and stencil testing is disabled in the D24S8 format, then a pixel written after rendering will contain 3 valid bytes (i.e., depth bytes) and one invalid byte (i.e., stencil byte). Therefore, a 32-byte data packet will contain 8 valid depth data and 8 invalid stencil data. However, due to limitations of the PCIe protocol, a 32-byte data packet will be split and repackaged from consecutive valid bytes, and the packet will be split at the invalid bytes. Accordingly, the aforementioned 32-byte data packet will be split into 8 independent data packets and sent to system memory. This processing method not only leads to a dramatic increase in the number of data packets sent by the GPU, but also fails to fully utilize the effective bandwidth of PCIe, causing a significant drop in GPU performance. Figure 3 In the data structure, each depth byte is followed by a template byte. Since the template byte is considered invalid during the process of being passed back to system memory, the data packet needs to be split at the template byte (i.e., invalid byte) when encapsulating the data packet. Correspondingly, in... Figure 3 As shown, in the case of three sets of depth bytes, this will result in three data packets. Of course, Figure 3 This is for illustrative purposes only. In practice, it typically contains eight groups of depth bytes, which are then split into eight data packets.

[0100] Therefore, it is evident that in the traditional method of interleaving depth bytes and template bytes, the template bytes are in an invalid state, leading to unnecessary packet splitting overhead. Furthermore, it should be noted that even if template testing is enabled, the aforementioned problem will still occur if template values ​​are not written to system memory (i.e., only depth values ​​are written to system memory, not template values).

[0101] To address the aforementioned issues, this example optimizes the depth write-out scenario implemented via PCIe in the D24S8 format using the GPU. It proposes a mode that separates the storage of depth and template data, ensuring the correct execution of depth testing while mitigating the performance degradation caused by PCIe data unpacking. This approach solves the problem of depth-only (zonly) scenes in the D24S8 format rendering at a relatively low cost.

[0102] Specifically, this example adds a depth and template separation storage mode under the D24S8 format. In this mode, D24S8 format data is not stored as a combination of 24-bit depth values ​​and 8-bit template values. Instead, the two are forcibly separated. The GPU creates two storage surfaces: one for storing depth values ​​and the other for storing template values. In the depth surface, each element occupies 32 bits, with 24 bits being valid depth data and 8 bits reserved for placeholders. In the template surface, each element occupies 8 bits. Figure 4 A schematic diagram of a depth surface is shown. Figure 5 A schematic diagram of the template surface is shown.

[0103] like Figure 4 As shown, a depth element contains 3 depth bytes and 1 null byte (such as a placeholder). Therefore, although the actual effective bit width of a depth element is 24 bits, it is accessed at a granularity of 32 bits / pixel during rendering. Special handling based on the mode settings is only needed when truncating the effective bit width. This demonstrates that... Figure 4 and Figure 5 In this process, the depth surface and the template surface are stored separately, and the depth surface contains null bytes with the same bit width as the template.

[0104] In practice, firstly, when the GPU driver detects that the rendering scene uses the D24S8 format and must be written to system memory via PCIe, it can enable the depth and stencil separate storage mode. At the same time, it is necessary to allocate a storage space for depth and stencil, namely the depth surface and stencil surface mentioned above.

[0105] Then, during the depth loading process, the separate storage mode based on D24S8 will affect the depth loading and writing process. Specifically, during rendering, when depth data needs to be loaded from GPU memory, the depth testing module first determines whether the storage mode of depth and template is separate storage mode. If the result is yes, the depth data (i.e., the rendering depth data mentioned above) is loaded from the depth surface first, with each depth element being 32 bits. After the depth data is loaded into the depth testing module, it is still temporarily stored in 32-bit form. Whenever the depth value is retrieved during the depth test, the lower 24 bits of a value from one element of the depth data (i.e., the initial depth value) need to be truncated, and the truncated lower 24 bits are used for the depth test.

[0106] Additionally, if template testing is also enabled at this time, the template data needs to be loaded from the template surface again; otherwise, the template data loading process is skipped.

[0107] Figure 6 This diagram illustrates the process of loading depth data from GPU memory to the local depth testing module. (For example...) Figure 6 As shown, the depth byte 0 and placeholder 0 in the data packet together constitute a 32-bit depth element. Accordingly, when loading the depth elements into the depth testing module, for each depth element, the lower 24 bits of the depth byte are truncated from its 32 bits, and the higher 8 bits of the placeholder are discarded. For example, truncating depth byte 0 yields the depth byte in pixel 0. Figure 6 The example given is to determine three pixels based on three depth elements. In practice, the number of depth elements is usually eight, and the number of pixels obtained is also eight.

[0108] After the depth test is completed, the next step is to package the depth bytes (i.e., the target depth value) of each pixel and transfer them to system memory. Correspondingly, when writing the depth data to system memory, the current storage mode must also be checked: The depth test module first determines the storage mode of the depth and template. If it is a separate storage mode and depth needs to be written, the following operations are performed: First, the depth data is extracted from the local storage module of the depth test module, and 24 bits of the 32-bit elements are truncated for use. The depth test module still packages the truncated elements into 32-bit elements; in other words, each pixel has an 8-bit placeholder, usually with a value of 0. This data is then compiled into a packet and written to external storage (i.e., system memory). Additionally, if template data needs to be stored, it is then extracted from the local storage module, packaged into 8-bit elements, compiled into a packet, and written to external storage.

[0109] Figure 7 This diagram illustrates the process of writing depth data from the depth testing module to system memory. For example... Figure 7 As shown, the depth bytes and placeholders in each pixel are packaged together. Since the placeholders are recognized as valid bytes, the problem of data packets being split due to invalid bytes is avoided. Figure 7 This example uses three pixels as an illustration; in reality, the number of pixels is usually eight. Figure 6 and Figure 7 The shaded area in the image represents a placeholder.

[0110] In summary, this example optimizes depth write scenarios via PCIe in the D24S8 format on the GPU. It addresses the issue of surging write data volume caused by PCIe protocol truncation by implementing a depth and stencil separation storage mode. This special storage mode requires special processing (such as truncation and padding) of depth values ​​during loading and writing to ensure the correctness of the rendering results. This method solves the aforementioned data write problem via PCIe with low complexity and a small area, improving GPU performance in the above scenario. Experimental tests show that applying this mode to D24S8 depth write scenarios via PCIe can achieve a performance improvement of nearly 100 times. In conclusion, this example significantly improves PCIe write bandwidth utilization with minimal area impact through the D24S8 depth and stencil separation storage mode and special processing of depth values ​​during depth loading and writing.

[0111] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0112] In addition, this disclosure also provides a processing apparatus for rendering depth data, an electronic device, and a computer-readable storage medium, all of which can be used to implement any of the methods provided in this disclosure. The corresponding technical solutions and descriptions are described in the corresponding records in the method section and will not be repeated here.

[0113] Figure 8 This is a block diagram of a rendering depth data processing apparatus provided in an embodiment of the present disclosure.

[0114] Reference Figure 8 This disclosure provides a processing apparatus for rendering depth data, the apparatus comprising:

[0115] The loading module 81 is adapted to load the rendering depth data from the first storage space; the rendering depth data is characterized by a preset format, which is used to define the storage method of the initial depth value of the first bit length and the template value of the second bit length.

[0116] Test module 82 is adapted to perform a depth test based on the initial depth value in the rendered depth data, and obtain the target depth value based on the depth test result;

[0117] The generation module 83 is adapted to generate target depth data corresponding to the target depth value; the target depth data includes: the target depth value and a target placeholder, wherein the target depth value is the first number of bits and the target placeholder is the second number of bits;

[0118] The encapsulation module 84 is adapted to encapsulate the target depth data into a data packet, so as to transmit the encapsulated data packet to the second storage space via a data bus.

[0119] In one alternative implementation, before loading the rendering depth data from the first storage space, the method further includes:

[0120] If the current storage mode is determined to be a pre-configured separate storage mode, a depth buffer is created in the first storage space;

[0121] The depth buffer is used to store the rendering depth data, and each element in the rendering depth data includes: an initial depth value of the first bit length and an initial placeholder of the second bit length.

[0122] In one alternative implementation, if the current storage mode is determined to be a pre-configured separate storage mode, a template buffer that is separate from the depth buffer is further created in the first storage space.

[0123] The template buffer is used to store template data, and each element in the template data includes: the template value of the second bit length.

[0124] In one alternative implementation, loading the rendering depth data from the first storage space includes:

[0125] Load the rendering depth data from the depth buffer;

[0126] For any element in the rendered depth data, extract the initial depth value of the first bit depth contained in the element.

[0127] In one optional implementation, determining that the current storage mode is a pre-configured separate storage mode includes:

[0128] If the received depth buffer creation request meets the preset separate storage conditions, the current storage mode is determined to be the pre-configured separate storage mode;

[0129] The preset separate storage conditions include:

[0130] The data format corresponding to the depth buffer creation request is the preset format;

[0131] The target depth value needs to be transmitted to the second storage space; and,

[0132] Template testing is not enabled, or the data transferred to the second storage space does not contain template values.

[0133] In one optional implementation, determining that the current storage mode is a pre-configured separate storage mode when the received depth buffer creation request meets preset separate storage conditions includes:

[0134] If the received depth buffer creation request is determined to meet the preset separate storage conditions, the register state of the preset register is configured to the preset state.

[0135] If the register state of the preset register is detected to be the preset state, the current storage mode is determined to be the pre-configured separate storage mode.

[0136] In one alternative implementation, the method is executed by a depth testing module included in the graphics processor;

[0137] Furthermore, the first storage space includes: the local memory space in the graphics processor; the second storage space includes: the system memory space of the device where the graphics processor is located.

[0138] In one optional implementation, transmitting the encapsulated data packet to the second storage space includes: transmitting the encapsulated data packet to the system memory space via a peripheral component interconnection protocol; wherein, the target placeholder in the target depth data and the target depth value both belong to valid bytes.

[0139] In one optional implementation, the preset format is a joint format based on an M-bit depth N-bit template, where M and N are natural numbers; and the first bit has M bits and the second bit has N bits.

[0140] In addition, another embodiment of this disclosure provides a rendering depth data processing system, including the above-described rendering depth data processing apparatus.

[0141] Additionally, this disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the method as described above.

[0142] Figure 9This is a block diagram of an electronic device provided in an embodiment of the present disclosure.

[0143] Reference Figure 9 This disclosure provides an electronic device, which includes: at least one processor 401; at least one memory 402; and one or more I / O interfaces 403 connected between the processor 401 and the memory 402; wherein the memory 402 stores one or more computer programs that can be executed by the at least one processor 401, and the one or more computer programs are executed by the at least one processor 401 to enable the at least one processor 401 to perform the above-described method.

[0144] This disclosure also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program implements the above-described method when executed by a processor. The computer-readable storage medium may be a volatile or non-volatile computer-readable storage medium.

[0145] This disclosure also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in a processor of an electronic device, the processor in the electronic device performs the above-described method.

[0146] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0147] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0148] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0149] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0150] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0151] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0152] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0153] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0154] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0155] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A processing method of rendering depth data, characterized in that, The method comprises: loading the rendering depth data from a first storage space; the rendering depth data is represented by a preset format, the preset format is used to define a storage manner of an initial depth value of a first bit number and a stencil value of a second bit number; performing a depth test according to the initial depth value in the rendering depth data, and obtaining a target depth value according to a depth test result; generating target depth data corresponding to the target depth value; the target depth data comprises the target depth value and a target placeholder, the target depth value is the first bit number, and the target placeholder is the second bit number; encapsulating the target depth data into a data packet, and transmitting the encapsulated data packet to a second storage space through a data bus.

2. The method of claim 1, wherein, Before the loading of the rendering depth data from the first storage space, the method further comprises: in a case where it is determined that a current storage mode is a preconfigured separate storage mode, creating a depth buffer in the first storage space; wherein the depth buffer is used to store the rendering depth data, and each element in the rendering depth data comprises an initial depth value of the first bit number and an initial placeholder of the second bit number.

3. The method of claim 2, wherein, in a case where it is determined that the current storage mode is the preconfigured separate storage mode, further creating a stencil buffer separate from the depth buffer in the first storage space; wherein the stencil buffer is used to store stencil data, and each element in the stencil data comprises a stencil value of the second bit number.

4. The method of claim 2, wherein, The loading of the rendering depth data from the first storage space comprises: loading the rendering depth data from the depth buffer; for any element in the rendering depth data, extracting the initial depth value of the first bit number contained in the element.

5. The method of claim 2, wherein, The determination that the current storage mode is the preconfigured separate storage mode comprises: in a case where it is determined that a received depth buffer creation request meets a preset separate storage condition, determining that the current storage mode is the preconfigured separate storage mode; wherein the preset separate storage condition comprises: a data format corresponding to the depth buffer creation request is the preset format; the target depth value needs to be transmitted to the second storage space; and stencil test is not enabled, or no stencil value is included in data transmitted to the second storage space.

6. The method of claim 5, wherein, The determination that the current storage mode is the preconfigured separate storage mode in a case where it is determined that the received depth buffer creation request meets the preset separate storage condition comprises: in a case where it is determined that the received depth buffer creation request meets the preset separate storage condition, a register state of a preset register is configured to be a preset state; in a case where it is detected that the register state of the preset register is the preset state, determining that the current storage mode is the preconfigured separate storage mode.

7. The method according to any of claims 1 to 6, characterized in that The method is performed by a depth test module included in a graphics processor; and the first storage space comprises a local memory space in the graphics processor; and the second storage space comprises a system memory space of a device where the graphics processor is located.

8. The method of claim 7, wherein, The transmitting the encapsulated data packet to the second storage space comprises: transmitting the encapsulated data packet to the system memory space through a peripheral component interconnect protocol; wherein the target placeholder and the target depth value in the target depth data belong to a valid byte.

9. A processing device for rendering depth data, characterized in that The apparatus comprises: a loading module adapted to load the rendering depth data from a first storage space; the rendering depth data is represented by a preset format, and the preset format is used to define a storage manner of an initial depth value with a first bit number and a template value with a second bit number; a testing module adapted to perform a depth test according to the initial depth value in the rendering depth data, and obtain a target depth value according to a depth test result; a generating module adapted to generate target depth data corresponding to the target depth value; the target depth data comprises the target depth value and a target placeholder, the target depth value is the first bit number, and the target placeholder is the second bit number; an encapsulating module adapted to encapsulate the target depth data into a data packet, and transmit the encapsulated data packet to a second storage space through a data bus.

10. An image rendering system, characterized by The apparatus comprises: The rendering depth data processing apparatus of claim 9.

11. An electronic device, comprising: The apparatus comprises: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores one or more computer programs executable by the at least one processor, and the one or more computer programs are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

12. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program, when executed by a processor, implements the method of any one of claims 1-8.

13. A computer program product comprising computer readable code, or a non-transitory computer readable storage medium having computer readable code embodied thereon, the computer readable code comprising instructions for causing a computer to perform the method of any one of claims 1 to 12. When the computer readable code runs in an electronic device, a processor in the electronic device performs the method of any one of claims 1-8.

Images