CN117274033B - Graphic driving debugging method and device, storage medium and electronic equipment - Google Patents
Graphic driving debugging method and device, storage medium and electronic equipment Download PDFInfo
- Publication number
- CN117274033B CN117274033B CN202311541971.2A CN202311541971A CN117274033B CN 117274033 B CN117274033 B CN 117274033B CN 202311541971 A CN202311541971 A CN 202311541971A CN 117274033 B CN117274033 B CN 117274033B
- Authority
- CN
- China
- Prior art keywords
- rendering
- accessory
- debugging
- determining
- related information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 78
- 238000009877 rendering Methods 0.000 claims abstract description 159
- 238000012545 processing Methods 0.000 claims description 59
- 238000004364 calculation method Methods 0.000 claims description 27
- 239000012634 fragment Substances 0.000 claims description 24
- 238000004590 computer program Methods 0.000 claims description 13
- 230000006870 function Effects 0.000 description 17
- 238000004891 communication Methods 0.000 description 12
- 239000008186 active pharmaceutical agent Substances 0.000 description 9
- 238000010586 diagram Methods 0.000 description 6
- 230000003139 buffering effect Effects 0.000 description 5
- 238000011161 development Methods 0.000 description 4
- 230000005236 sound signal Effects 0.000 description 4
- 239000011800 void material Substances 0.000 description 4
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- KLDZYURQCUYZBL-UHFFFAOYSA-N 2-[3-[(2-hydroxyphenyl)methylideneamino]propyliminomethyl]phenol Chemical compound OC1=CC=CC=C1C=NCCCN=CC1=CC=CC=C1O KLDZYURQCUYZBL-UHFFFAOYSA-N 0.000 description 1
- 241001289753 Graphium sarpedon Species 0.000 description 1
- 230000002159 abnormal effect Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 239000003086 colorant Substances 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 201000001098 delayed sleep phase syndrome Diseases 0.000 description 1
- 208000033921 delayed sleep phase type circadian rhythm sleep disease Diseases 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000004927 fusion Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000010977 unit operation Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T1/00—General purpose image data processing
- G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
Abstract
The disclosure relates to a method and a device for debugging graphic drive, a storage medium and electronic equipment. The method comprises the following steps: constructing a debugging accessory of the graphic driver, wherein the debugging accessory is used for storing debugging information of the graphic driver; acquiring image rendering related information of the graphic driver according to the debugging accessory; and determining the fault point of the graphic driver according to the image rendering related information. The embodiment of the disclosure can conveniently obtain the internal data of the graphic driver and the internal data of the hardware unit of the display card, is simple and convenient to operate, and can improve the debugging and developing efficiency of the graphic driver of the display card.
Description
Technical Field
The present disclosure relates to the field of image data processing technologies, and in particular, to a graphics driver debugging method, a graphics driver debugging device, a storage medium, and an electronic device.
Background
Currently, graphics are rendered mainly by calling a graphics API such as Vulkan, directX, openGL. In view of robustness and completeness of graphics API, some state check affecting rendering efficiency is often performed inside the driver, and some characteristics that may not be used are necessary to initialize or allocate related data and further affect rendering efficiency.
The display card device provides three-dimensional graphic calculation and parallel processing functions, and for related application program development, it is necessary to know whether each step of the program accords with expectations; for development of a graphics card driver, it is necessary to know the instruction details received by the hardware device after each instruction is issued. In addition, in some specific situations, it is necessary to know the calculation result and the unit state of a specific calculation unit.
However, the existing method for debugging the graphics driver cannot conveniently obtain the internal data of the driver and the internal data of the graphics card hardware unit, is inconvenient to operate, and affects the debugging and developing efficiency of the graphics driver of the graphics card. Therefore, a new graphic driver debugging method is needed to better meet the debugging and development work of graphic driver of the display card, and improve the debugging and development efficiency of graphic driver of the display card.
Disclosure of Invention
The purpose of the present disclosure is to provide a method, an apparatus, a storage medium, and an electronic device for debugging graphics driver, which can conveniently obtain internal data of graphics driver and internal data of graphics card hardware unit, and has simple operation, and can improve the debugging development efficiency of graphics driver of graphics card.
To achieve the above object, according to a first aspect of embodiments of the present disclosure, there is provided a graphics-driven debugging method, the method including:
Constructing a debugging accessory of the graphic driver, wherein the debugging accessory is used for storing debugging information of the graphic driver;
acquiring image rendering related information of the graphic driver according to the debugging accessory;
and determining the fault point of the graphic driver according to the image rendering related information.
Optionally, the building the graphics-driven debug accessory includes:
defining an accessory object of the debug accessory;
defining a parameter object of the debug accessory;
declaring the debug accessory;
creating a channel structure of the debug accessory.
Optionally, the determining, according to the image rendering related information, a fault point of the graphics driver includes:
operating the graphic driver to acquire the difference between the real-time rendering image and the expected rendering image;
determining a pipeline rendering stage at which a fault occurs according to the difference between the real-time rendering image and the expected rendering image;
determining intermediate information in the processing process of a processing unit corresponding to the pipeline rendering stage according to the pipeline rendering stage where the fault occurs;
according to the intermediate information, rendering related information of the real-time rendering image is obtained;
And the rendering related information is put into the debugging accessory, and the fault point of the graphic driver is determined according to the debugging accessory.
Optionally, the determining, according to the pipeline rendering stage where the fault occurs, intermediate information in a processing procedure of a processing unit corresponding to the pipeline rendering stage includes:
determining unified variables input in the processing process of a processing unit corresponding to the pipeline rendering stage;
determining variable information transferred in a previous stage of the pipeline rendering stage;
and determining intermediate information in the processing process of the processing unit according to the unified variable and variable information transmitted in the last stage of the pipeline rendering stage.
Optionally, the acquiring the rendering related information of the real-time rendering image according to the intermediate information includes:
determining a designated calculation unit according to a specific variable built in the fragment shader;
and determining coordinate values of the window corresponding to the current fragment according to the calculation result of the specified calculation unit.
Optionally, the acquiring the rendering related information of the real-time rendered image according to the intermediate information further includes:
and acquiring rendering related information of the pixel point corresponding to the coordinate value according to the coordinate value of the window corresponding to the current segment.
Optionally, the placing the rendering related information into the debug accessory, and determining, according to the debug accessory, a fault point of the graphics driver includes:
acquiring the rendering related information by decoding the debug accessory;
and determining the fault point of the graphic driver according to the rendering related information.
Optionally, the placing the rendering related information into the debug accessory, and determining, according to the debug accessory, a fault point of the graphics driver includes:
superposing the debugging accessory on the color accessory, and outputting a debugging graph to a display end;
and determining the fault point of the graphic driver according to the debugging graphic.
According to a second aspect of embodiments of the present disclosure, there is provided a graphics-driven debugging apparatus, the debugging apparatus comprising:
the building module is used for building a debugging accessory of the graphic driver, and the debugging accessory is used for storing the debugging information of the graphic driver;
the acquisition module is used for acquiring image rendering related information of the graphic driver according to the debugging accessory;
and the determining module is used for determining the fault point of the graphic driver according to the image rendering related information.
According to a third aspect of embodiments of the present disclosure, there is provided a non-transitory computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of the method of any of the first aspects.
According to a fourth aspect of embodiments of the present disclosure, there is provided an electronic device, comprising:
a memory having a computer program stored thereon;
a processor for executing the computer program in the memory to implement the steps of the method of any of the first aspects.
In summary, an embodiment of the present disclosure provides a method for graphics driver debug, including: constructing a debugging accessory of the graphic driver, wherein the debugging accessory is used for storing debugging information of the graphic driver; acquiring image rendering related information of the graphic driver according to the debugging accessory; and determining the fault point of the graphic driver according to the image rendering related information. The embodiment of the disclosure can conveniently obtain the internal data of the graphic driver and the internal data of the hardware unit of the display card, is simple and convenient to operate, and can improve the debugging and developing efficiency of the graphic driver of the display card.
Additional features and advantages of the present disclosure will be set forth in the detailed description which follows.
Drawings
The accompanying drawings are included to provide a further understanding of the disclosure, and are incorporated in and constitute a part of this specification, illustrate the disclosure and together with the description serve to explain, but do not limit the disclosure. In the drawings:
FIG. 1 is a flowchart illustrating a graphics-driven debug method, according to an example embodiment.
FIG. 2 is a flowchart illustrating a method of constructing a graphics-driven debug accessory in accordance with an exemplary embodiment.
FIG. 3 is a flowchart illustrating a method of determining a failure point of a graphics driver, according to an example embodiment.
FIG. 4 is a flowchart illustrating a method of determining intermediate information during processing by a processing unit corresponding to a pipeline rendering stage, according to an example embodiment.
Fig. 5 is a flowchart illustrating a method of acquiring rendering-related information of a real-time rendered image according to an exemplary embodiment.
Fig. 6 is a flowchart illustrating yet another method of acquiring rendering-related information of a real-time rendered image according to an exemplary embodiment.
FIG. 7 is a flowchart illustrating yet another method of determining a failure point of a graphics driver, according to an example embodiment.
FIG. 8 is a flowchart illustrating yet another method of determining a failure point of a graphics driver, according to an example embodiment.
Fig. 9 is a block diagram illustrating a graphics-driven debugging device 900, according to an example embodiment.
Fig. 10 is a block diagram of an electronic device 1000, shown in accordance with an exemplary embodiment.
Fig. 11 is a block diagram of an electronic device 1100, according to an example embodiment.
Detailed Description
Specific embodiments of the present disclosure are described in detail below with reference to the accompanying drawings. It should be understood that the detailed description and specific examples, while indicating and illustrating the disclosure, are not intended to limit the disclosure.
It should be understood that the term "include" and variations thereof as used herein are intended to be open-ended, i.e., "including but not limited to. The term "based on" is based at least in part on. The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments. Related definitions of other terms will be given in the description below.
It should be noted that the terms "first," "second," and the like in this disclosure are merely used to distinguish between different devices, modules, or units and are not used to define an order or interdependence of functions performed by the devices, modules, or units. The references to "a" and "an" in this disclosure are intended to be illustrative rather than limiting, and those of ordinary skill in the art will appreciate that "one or more" is intended to be understood as "one or more" unless the context clearly indicates otherwise. In the description of the present disclosure, unless otherwise indicated, "a plurality" means two or more than two, and other adjectives are similar thereto; "at least one item", "an item" or "a plurality of items" or the like, refer to any combination of these items, including any combination of single item(s) or plural items(s).
Although operations or steps are described in a particular order in the figures in the disclosed embodiments, it should not be understood as requiring that such operations or steps be performed in the particular order shown or in sequential order, or that all illustrated operations or steps be performed, to achieve desirable results. In embodiments of the present disclosure, these operations or steps may be performed serially; these operations or steps may also be performed in parallel; some of these operations or steps may also be performed.
The names of messages or information interacted between the various devices in the embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information. It will be appreciated that prior to using the technical solutions disclosed in the embodiments of the present disclosure, the user should be informed and authorized of the type, usage range, usage scenario, etc. of the personal information related to the present disclosure in an appropriate manner according to the relevant legal regulations. The present disclosure is described below in connection with specific embodiments.
First, an application scenario of the present disclosure will be described. There are several ways currently available for debugging graphics cards and applications:
A debug interface provided using a graphics API such as OpenGL, vulkan. The common debug interfaces provided by OpenGL, for example, are as follows:
GLAPI void APIENTRY glDebugMessageControl (GLenum source, GLenum type, GLenum severity, GLsizei count, const GLuint *ids, GLboolean enabled);
GLAPI void APIENTRY glDebugMessageInsert (GLenum source, GLenum type, GLuint id, GLenum severity, GLsizei length, const GLchar *buf);
GLAPI void APIENTRY glDebugMessageCallback (GLDEBUGPROC callback, const void *userParam);
GLAPI GLuint APIENTRY glGetDebugMessageLog (GLuint count, GLsizei bufSize, GLenum *sources, GLenum *types, GLuint *ids, GLenum *severities, GLsizei *lengths, GLchar *messageLog);
the functions are that setting the debug information type to be reported by the debug context; inserting a piece of debugging information into the debugging context; setting a debug message callback function; and obtaining a debugging information log. By using the method, whether the program uses the API correctly or not and rough debugging information in aspects of window system, shader compiling and the like can be known. However, the internal data of the graphics card hardware unit is often not available.
The instruction sent to the display card driver by the graphics driver is intercepted in real time by using an export ld_preload=/XXX under similar linux. The method can effectively acquire the descriptor information actually received by the display card, but can not obtain the internal data of the driver and the data in the hardware unit. Consider that modern graphics APIs have the concept of buffering or attachment. For example, in OpenGL/GLES, there is color buffering and depth buffering, where buffering is understood to be a section of memory containing specific information. The attachments in Vulkan and the like, except that the buffer is modified to contain a set of attachments. For the color accessory and depth buffer described above, an input accessory is added. The input attachment is a set of image views that can be read directly in the shader.
The essence of the debugging of the display card or other equipment is that the CPU end obtains the intermediate data which is interested by the debugger in the calculation process on the display card (equipment); or the related data is displayed on the display end. Based on this, the technical scheme that this disclosure put forward is as follows:
in buffering (in OpenGL), attachment (in Vulkan) builds a unit dedicated to debugging, i.e. a debug attachment. For a graphics GPU, the end result is rendered to the terminal device. In the image output stage, the debugging information interested by the user can be pushed to the user in front of the user in a debugging accessory mode according to the user setting, and the information in the debugging accessory can be displayed as displayable information in a demodulation mode and is displayed to the user in a using mode. The debug accessory can also be superimposed on the color accessory in a specific manner for final output to the display. The user can determine the fault information by looking up the output graph.
FIG. 1 is a flowchart illustrating a graphics-driven debug method, according to an example embodiment. As shown in fig. 1, an embodiment of the present disclosure provides a method for graphics-driven debugging, which may include the following steps:
in step S10, a debug attachment of a graphics driver is constructed, where the debug attachment is used to store debug information of the graphics driver.
In this step, a debug attachment of the graphics driver is constructed, the debug attachment being used to store debug information of the graphics driver. By way of example, a debug attachment of a graphics driver may be constructed which may be used to store debug information of the graphics driver, such as site shader information, geometry shader information, subdivision shader information, pixel shader information, erroneous image frame sequence numbers, API execution instruction numbers, screen coordinate points to be recorded, and intermediate data of hardware unit operations, etc.
In step S20, image rendering related information of the graphics driver is acquired according to the debug accessory.
In this step, image rendering related information of the graphics driver is acquired according to the debug accessory. For example, image rendering related information of a graphics driver may be obtained from a debug accessory by defining related functions and objects.
For example, an object DebugAttachmentBuffer is defined to describe a data cache location corresponding to the debug accessory, an object debugvertecinfo is defined to describe fixed-point shader information, an object debugeomifo is defined to describe geometry shader information, an object debugtelellinfo is defined to describe subdivision shader information, an object debugfracinfo is defined to describe pixel shader information, an object gputfo is defined to describe corresponding Gpu information, which may include Gpu model number, number of parallel cores supported, and GPU core ID, running step ID where the debug accessory is running, and the like. Defining a function interface (decoder) the debug decoder is used to decode debug attachments, and exemplary, the partial code of the decode function interface implementation may be as follows:
class DebugAttachmentDecoder
{
public:
virtual ~DebugAttachmentDecoder() = 0;
public:
virtual bool decodeDebugAttachmentBuffer(DebugAttachmentBuffer*
buffer) = 0;
virtual std::shared_ptr<DebugVertexInfo>getVertexInfo()const = 0;
virtual std::shared_ptr<DebugFragmentInfo>getFragmentInfo()const = 0;
virtual std::shared_ptr<DebugGeomInfo>getGeomInfo()const = 0;
virtual std::shared_ptr<DebugTellInfo>getTellInfo()const = 0;
virtual std::string getRegisterString()const = 0;
virtual std::shared_ptr<GpuInfo>getGpuInfo()const = 0;
private:
};
Wherein the function getRegisterString is used to obtain register related information. If the debug accessory records the debug information in the subdivision shader, only getTellInfo in the relevant getXXXInfo returns data, and other function returns are all 0.
In step S30, a failure point of the graphics driver is determined according to the image rendering related information.
In this step, a failure point of the graphic driver is determined according to the image rendering related information. Illustratively, describing a fragment shader computation error as an example, if some image colors in the final image are displayed greenish, it is described that there is a problem with processing color information in the fragment shader. All that is required is to record relevant intermediate information, such as specific input unitorm variables, variable information transmitted in the last stage, and calculation results of built-in functions of the shader, etc. in the processing procedure of the fragment shader processing unit.
Considering that the processing of fragments is parallel processing, we need to specify which units of calculated intermediate process data need to be acquired. In this regard, the computational unit may be specified by a special variable built into the fragment shader. Such as gl_fragcoord, is used to mark window coordinate values (x, y, z, w) corresponding to the current segment, where x, y, z, and w represent the x-axis value, the y-axis value, the z-axis value, and the modulus of the coordinate vector, respectively.
Thus, window coordinates can be passed to the debugger before debugging, and if the current fragment processing unit undertakes the calculation of the coordinate pixels during the parallel calculation of the fragment shader, relevant information is recorded during the calculation. Relevant information is placed in the debug accessory at rendering time. When the program performs image rendering, the debugging accessory information is taken through the graphic API interface function, and then decoded and displayed to the user.
In summary, an embodiment of the present disclosure provides a method for graphics driver debug, including: constructing a debugging accessory of the graphic driver, wherein the debugging accessory is used for storing debugging information of the graphic driver; acquiring image rendering related information of the graphic driver according to the debugging accessory; and determining the fault point of the graphic driver according to the image rendering related information. The embodiment of the disclosure can conveniently obtain the internal data of the graphic driver and the internal data of the hardware unit of the display card, is simple and convenient to operate, and can improve the debugging and developing efficiency of the graphic driver of the display card.
FIG. 2 is a flowchart illustrating a method of constructing a graphics-driven debug accessory in accordance with an exemplary embodiment. As shown in FIG. 2, the building of the graphics-driven debug accessory may include the following steps:
In step S101, an accessory object of the debug accessory is defined.
In this step, an accessory object of the debug accessory is defined. Illustratively, the portion of code defining the accessory object of the debug accessory may be as follows:
VkAttachmentDescription debugAttachment{};
debugAttachment.format = VK_FORMAT_R16G16B16A16_UINT;
debugAttachment.samples = VK_SAMPLE_COUNT_1_BIT;
debugAttachment.loadOp = VK_ATTACHMENT_LOAD_OP_CLEAR;
debugAttachment.storeOp = VK_ATTACHMENT_STORE_OP_DONT_CARE;
debugAttachment.stencilLoadOp = VK_ATTACHMENT_LOAD_OP_DONT_CARE;
debugAttachment.stencilStoreOp = VK_ATTACHMENT_STORE_OP_DONT_CARE;
debugAttachment.initialLayout = VK_IMAGE_LAYOUT_UNDEFINED;
debugAttachment.finalLayout = VK_IMAGE_LAYOUT_DEBUG_ATTACHMENT_
OPTIMAL;
in step S102, a parameter object of the debug accessory is defined.
In this step, parameter objects of the debug accessory are defined. Illustratively, the portion of code defining the parameter object of the debug accessory may be as follows:
VkAttachmentReference debugAttachmentResolveRef{};
debugAttachmentResolveRef.attachment = 3;
debugAttachmentResolveRef.layout = VK_IMAGE_LAYOUT_DEBUG_ATTACHMENT_
OPTIMAL;
in step S103, the debug accessory is declared.
In this step, the debug accessory is declared. Illustratively, the portion of code declaring a debug accessory may be as follows:
std::array<VkAttachmentDescription, 4>attachments = {colorAttachment,
depthAttachment, colorAttachmentResolve,debugAttachment };
in step S104, a channel structure of the debug accessory is created.
In this step, a channel structure of the debug accessory is created. Illustratively, the portion of code of the channel structure that creates the debug accessory may be as follows:
VkRenderPassCreateInfo renderPassInfo{};
renderPassInfo.sType = VK_STRUCTURE_TYPE_RENDER_PASS_CREATE_INFO;
renderPassInfo.attachmentCount = static_cast<uint32_t>
(attachments.size());
renderPassInfo.pAttachments = attachments.data();
renderPassInfo.subpassCount = 1;
renderPassInfo.pSubpasses =&subpass;
renderPassInfo.dependencyCount = 1;
renderPassInfo.pDependencies =&dependency;
if (vkCreateRenderPass(context->getDevice(),&renderPassInfo, context-
>getAllocation(),
&renderPass) != VK_SUCCESS) {
std::cerr<<"failed to create render pass"<<std::endl;
}
FIG. 3 is a flowchart illustrating a method of determining a failure point of a graphics driver, according to an example embodiment. As shown in fig. 3, the determining the fault point of the graphics driver according to the image rendering related information may include the following steps:
In step S301, the graphics driver is operated to acquire a difference between a real-time rendered image and an expected rendered image.
In this step, a graphics driver is run to obtain the difference of the real-time rendered image and the intended rendered image. For example, differences in real-time rendered images from intended rendered images may include differences in image color misalignment, image position misalignment, image geometry misalignment, and the like.
In step S302, a pipeline rendering stage at which a fault occurs is determined according to a difference between the real-time rendered image and an expected rendered image.
In this step, a pipeline rendering stage at which a fault occurs is determined from the difference of the real-time rendered image and the expected rendered image. For example, if the final rendered image is not color-to-color (e.g., yellowish), then the failure may occur in a fragment shader rendering stage, a rasterizer rendering stage, or a test fusion stage; if the position of the rendered image is not right (e.g., left, right, or small), then the failure must be in the vertex shader rendering stage, geometry shader rendering stage, or subdivision shader rendering stage; if there is an image but the presentation form is not right (geometry is not right), then problems may occur in the primitive assembly phase or geometry shader rendering phase or subdivision shader rendering phase.
In step S303, according to the pipeline rendering stage where the fault occurs, intermediate information in the processing procedure of the processing unit corresponding to the pipeline rendering stage is determined.
In this step, according to the pipeline rendering stage where the fault occurs, intermediate information in the processing procedure of the processing unit corresponding to the pipeline rendering stage is determined. Illustratively, based on the difference between the first displayed image and the expected image, the stage where the fault occurs may be initially determined to be at the shader stage, and if it is determined that the fragment shader has an error in calculation, relevant intermediate information may be recorded during the processing of the fragment shader processing unit, for example, specific input unimorph variable information, variable information transmitted from the previous stage, and the calculation result of a shader built-in function (for example, normal function, which is used to unitize a designated vector), etc.
In step S304, rendering related information of the real-time rendered image is acquired according to the intermediate information.
In this step, rendering-related information of the real-time rendered image is acquired based on the intermediate information. When the rendering result is abnormal, the graphics driver records the trace running at the time in the rendering process, and determines the image frame sequence and the graphics API function execution sequence number when the error occurs and the rendering related information of the real-time rendering image such as the specific input unique variable information recorded in the trace, the variable information transmitted in the last stage, the variable information transmitted in the current stage, the calculation result of the built-in function of the shader and the like.
In step S305, the rendering related information is put into the debug accessory, and a failure point of the graphics driver is determined according to the debug accessory.
In this step, rendering related information is put into the debug accessory, from which the failure point of the graphics driver is determined. Illustratively, the rendering related information is placed in the debug accessory, playback operations are performed according to the trace file just saved, the debug program automatically or manually pauses when running into the graphics API function execution sequence specified in the debug accessory, and the record fragment shader is displayed in context information (incoming variable, outgoing variable, used unitorm information, outgoing final color, etc.) related to the specified location (at the specific coordinates). If necessary, the designated instruction steps at the time of shader execution may be displayed here. Based on the above information, the above operations are repeated, so that the cause of the error can be analyzed, whether the variable calculation transmitted in the previous stage is wrong or the compiler in the present stage is wrong, and whether the compiler is wrong or the GPU hardware is wrong can be known by knowing the error step.
FIG. 4 is a flowchart illustrating a method of determining intermediate information during processing by a processing unit corresponding to a pipeline rendering stage, according to an example embodiment. As shown in fig. 4, the determining, according to the pipeline rendering stage where the fault occurs, intermediate information in a processing procedure of a processing unit corresponding to the pipeline rendering stage may include the following steps:
In step S3031, unified variables input during the processing of the processing units corresponding to the pipeline rendering stage are determined.
In this step, the information of the unified variable, i.e., the unimorph variable, input in the processing procedure of the processing unit corresponding to the pipeline rendering stage is determined.
In step S3032, variable information that was passed into a previous stage of the pipeline rendering stage is determined.
In this step, variable information incoming to the last stage of the pipeline rendering stage, such as r, g, b variable information outgoing from the vertex shader stage, is determined.
In step S3033, intermediate information in the processing procedure of the processing unit is determined according to the unified variable and variable information transferred in a previous stage of the pipeline rendering stage.
In this step, intermediate information in the processing of the processing unit is determined based on the unified variable and variable information entered at a stage preceding the pipeline rendering stage. Illustratively, considering that the processing for the pipeline rendering stage (e.g., fragment shader) is parallel processing, it is possible to determine which computational unit is required to obtain intermediate process information calculated from the unified unitorm variable information incoming at this stage, and variable information incoming at the previous stage, e.g., r, g, b variable information outgoing at the vertex shader stage.
Fig. 5 is a flowchart illustrating a method of acquiring rendering-related information of a real-time rendered image according to an exemplary embodiment. As shown in fig. 5, the acquiring the rendering related information of the real-time rendered image according to the intermediate information may include the following steps:
in step S3041, a specified calculation unit is determined from the specific variable built in the fragment shader.
In this step, the specified computational unit is determined from specific variables built into the fragment shader. For example, a special variable built into the fragment shader (such as gl_FragCoord) may be used to specify the compute unit.
In step S3042, the coordinate value of the window corresponding to the current segment is determined according to the calculation result of the specified calculation unit.
In this step, the coordinate value of the window corresponding to the current segment is determined according to the calculation result of the specified calculation unit. For example, the coordinate values (x, y, z, w) of the window corresponding to the current segment may be determined according to the calculation result of the designated calculation unit. Wherein x, y, z and w represent the x-axis value, the y-axis value, the z-axis value and the modulus of the coordinate vector, respectively.
Fig. 6 is a flowchart illustrating yet another method of acquiring rendering-related information of a real-time rendered image according to an exemplary embodiment. As shown in fig. 6, the acquiring the rendering related information of the real-time rendered image according to the intermediate information may further include the following steps:
In step S3043, according to the coordinate value of the window corresponding to the current segment, rendering related information of the pixel point corresponding to the coordinate value is obtained.
In the step, according to the coordinate value of the window corresponding to the current segment, rendering related information of the pixel point corresponding to the coordinate value is obtained. For example, the coordinate values of the window corresponding to the current fragment may be transmitted to the debugger, and when the fragment shader performs parallel computation, if the current fragment shader processing unit performs computation of the coordinate pixel, the rendering related information is recorded in the computation process, and the rendering related information is placed in the debug accessory during rendering.
FIG. 7 is a flowchart illustrating yet another method of determining a failure point of a graphics driver, according to an example embodiment. As shown in fig. 7, the step of placing the rendering related information into the debug accessory, and determining a fault point of the graphics driver according to the debug accessory may include the following steps:
in step S3051a, the rendering-related information is acquired by decoding the debug accessory.
In this step, rendering-related information is obtained by decoding the debug accessory. For example, the debug accessory may be decoded using a debug accessory decoder function debug attachmentdecoder to obtain rendering related information.
In step S3052a, a failure point of the graphics driver is determined according to the rendering related information.
In this step, a failure point of the graphics driver is determined based on the rendering related information. For example, the method steps for determining the failure point of the graphics driver according to the rendering related information may refer to the description of step S305, which is not repeated herein.
FIG. 8 is a flowchart illustrating yet another method of determining a failure point of a graphics driver, according to an example embodiment. As shown in fig. 8, the step of placing the rendering related information into the debug accessory, and determining a fault point of the graphics driver according to the debug accessory may include the following steps:
in step S3051b, the debug accessory is superimposed on the color accessory, and the debug graphic is output to the display terminal.
In this step, the debug accessory is superimposed on the color accessory, and the debug graphic is output to the display terminal. For example, the debugging information in the debugging accessory can be superimposed on the color accessory, drawn in the form of a debugging graph and output to the display end. For example, if a certain register value is illegal, a red small circle is drawn on a specific debug graphic (for example, triangle), and the position of the circle is determined according to the register type. If the register values are illegal values, drawing a plurality of red circles; if a divide by 0 error occurs in the shader, a blue triangle is drawn. The debug graphics and standard GPU color attachments are fused together at the time of rendering output to form the final debug graphics and displayed on the screen.
In step S3052b, a failure point of the graphics driver is determined according to the debug graphic.
In this step, a failure point of the graphics driver is determined from the debug graphics. Specific examples are described with reference to the previous step.
In summary, an embodiment of the present disclosure provides a method for graphics driver debug, including: constructing a debugging accessory of the graphic driver, wherein the debugging accessory is used for storing debugging information of the graphic driver; acquiring image rendering related information of the graphic driver according to the debugging accessory; and determining the fault point of the graphic driver according to the image rendering related information. The embodiment of the disclosure can conveniently obtain the internal data of the graphic driver and the internal data of the hardware unit of the display card, is simple and convenient to operate, and can improve the debugging and developing efficiency of the graphic driver of the display card.
Fig. 9 is a block diagram illustrating a graphics-driven debugging device 900, according to an example embodiment. As shown in fig. 9, an embodiment of the present disclosure provides a graphics-driven debugging device 900, where the device 900 may include the following modules:
a building module 910, configured to build a debug accessory of a graphics driver, where the debug accessory is configured to store debug information of the graphics driver;
An obtaining module 920, configured to obtain, according to the debug accessory, image rendering related information of the graphics driver;
a determining module 930, configured to determine a failure point of the graphics driver according to the image rendering related information.
Optionally, the building module 910 includes a first defining module for defining an accessory object of the debug accessory;
build module 910 includes a second definition module for defining parameter objects of the debug accessory;
build module 910 includes a declaration module for declaring the debug accessory;
build module 910 includes a creation module for creating a channel structure for the debug accessory.
Optionally, the determining module 930 includes a difference obtaining module for running the graphics driver to obtain a difference between the real-time rendered image and the expected rendered image;
the determining module 930 includes a rendering stage obtaining module configured to determine a pipeline rendering stage at which a fault occurs according to a difference between the real-time rendered image and an expected rendered image;
the determining module 930 includes an intermediate information obtaining module, configured to determine, according to a pipeline rendering stage where the fault occurs, intermediate information in a processing procedure of a processing unit corresponding to the pipeline rendering stage;
The determining module 930 includes a rendering related information obtaining module, configured to obtain rendering related information of the real-time rendered image according to the intermediate information;
the determining module 930 includes a fault determining module configured to put the rendering related information into the debug accessory, and determine a fault point of the graphics driver according to the debug accessory.
Optionally, the intermediate information obtaining module includes a unified variable determining module, configured to determine a unified variable input in a processing procedure of a processing unit corresponding to the pipeline rendering stage;
the intermediate information acquisition module comprises an incoming variable determination module for determining variable information incoming at a previous stage of the pipeline rendering stage;
the intermediate information acquisition module comprises an intermediate information acquisition sub-module which is used for determining intermediate information in the processing process of the processing unit according to the unified variable and variable information transmitted in the last stage of the pipeline rendering stage.
Optionally, the rendering related information obtaining module includes a calculating unit determining module, configured to determine a specified calculating unit according to a specific variable built in the fragment shader;
the rendering related information acquisition module comprises a window coordinate determination module, and is used for determining coordinate values of a window corresponding to the current fragment according to the calculation result of the specified calculation unit.
Optionally, the rendering related information obtaining module includes a rendering related information sub-module, configured to obtain rendering related information of a pixel point corresponding to the coordinate value according to the coordinate value of the window corresponding to the current segment.
Optionally, the fault determining module includes a decoding module, configured to obtain the rendering related information by decoding the debug accessory;
the fault determination module comprises a fault determination first sub-module which is used for determining a fault point of the graphic driver according to the rendering related information.
Optionally, the fault determining module comprises a graphic output module, which is used for superposing the debugging accessory on the color accessory and outputting the debugging graphic to a display end;
the fault determination module comprises a fault determination second sub-module which is used for determining the fault point of the graphic driver according to the debugging graphic.
The specific manner in which the various modules perform the operations in the apparatus of the above embodiments have been described in detail in connection with the embodiments of the method, and will not be described in detail herein.
In summary, an embodiment of the present disclosure provides a graphics-driven debug apparatus, including: the construction module is used for constructing a debugging accessory of the graphic driver, and the debugging accessory is used for storing debugging information of the graphic driver; the acquisition module is used for acquiring image rendering related information of the graphic driver according to the debugging accessory; and the determining module is used for determining the fault point of the graphic driver according to the image rendering related information. The embodiment of the disclosure can conveniently obtain the internal data of the graphic driver and the internal data of the hardware unit of the display card, is simple and convenient to operate, and can improve the debugging and developing efficiency of the graphic driver of the display card.
Fig. 10 is a block diagram of an electronic device 1000, shown in accordance with an exemplary embodiment. As shown in fig. 10, the electronic device 1000 may include: a processor 1001, and a memory 1002. The electronic device 1000 may also include one or more of a multimedia component 1003, an input/output (I/O) interface 1004, and a communication component 1005.
The processor 1001 is configured to control overall operations of the electronic device 1000 to complete all or part of the steps in the graphics driver debugging method described above. The memory 1002 is used to store various types of data to support operation at the electronic device 1000, which may include, for example, instructions for any application or method operating on the electronic device 1000, as well as application-related data, such as contact data, transceived messages, pictures, audio, video, and the like. The Memory 1002 may be implemented by any type or combination of volatile or non-volatile Memory devices, such as static random access Memory (Static Random Access Memory, SRAM for short), electrically erasable programmable Read-Only Memory (Electrically Erasable Programmable Read-Only Memory, EEPROM for short), erasable programmable Read-Only Memory (Erasable Programmable Read-Only Memory, EPROM for short), programmable Read-Only Memory (Programmable Read-Only Memory, PROM for short), read-Only Memory (ROM for short), magnetic Memory, flash Memory, magnetic disk, or optical disk. The multimedia component 1003 may include a screen and audio components. Wherein the screen may be, for example, a touch screen, the audio component being for outputting and/or inputting audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in the memory 1002 or transmitted through the communication component 1005. The audio assembly further comprises at least one speaker for outputting audio signals. The I/O interface 1004 provides an interface between the processor 1001 and other interface modules, which may be a keyboard, mouse, buttons, etc. These buttons may be virtual buttons or physical buttons. The communication component 1005 is used for wired or wireless communication between the electronic device 1000 and other devices. Wireless communication, such as Wi-Fi, bluetooth, near field communication (Near Field Communication, NFC for short), 2G, 3G, 4G, NB-IOT, eMTC, or other 5G, etc., or one or a combination of more of them, is not limited herein. The corresponding communication component 1005 may thus comprise: wi-Fi module, bluetooth module, NFC module, etc.
In an exemplary embodiment, the electronic device 1000 may be implemented by one or more application specific integrated circuits (Application Specific Integrated Circuit, abbreviated as ASIC), digital signal processors (Digital Signal Processor, abbreviated as DSP), digital signal processing devices (Digital Signal Processing Device, abbreviated as DSPD), programmable logic devices (Programmable Logic Device, abbreviated as PLD), field programmable gate arrays (Field Programmable Gate Array, abbreviated as FPGA), controllers, microcontrollers, microprocessors, or other electronic components for performing the graphics driven debugging method described above.
In another exemplary embodiment, a computer readable storage medium is also provided that includes program instructions that, when executed by a processor, implement the steps of the graphics-driven debugging method described above. For example, the computer readable storage medium may be the memory 1002 described above including program instructions executable by the processor 1001 of the electronic device 1000 to perform the graphics-driven debugging method described above.
Fig. 11 is a block diagram of an electronic device 1100, according to an example embodiment. For example, the electronic device 1100 may be provided as a server. Referring to fig. 11, the electronic device 1100 includes a processor 1122, which may be one or more in number, and a memory 1132 for storing computer programs executable by the processor 1122. The computer program stored in memory 1132 may include one or more modules each corresponding to a set of instructions. Further, the processor 1122 may be configured to execute the computer program to perform the graphics-driven debugging method described above.
In addition, the electronic device 1100 may further include a power supply component 1126 and a communication component 1150, the power supply component 1126 may be configured to perform power management of the electronic device 1100, and the communication component 1150 may be configured to enable communication of the electronic device 1100, e.g., wired or wireless communication. In addition, the electronic device 1100 may also include an input/output (I/O) interface 1158. The electronic device 1100 may operate based on an operating system stored in the memory 1132.
In another exemplary embodiment, a computer readable storage medium is also provided that includes program instructions that, when executed by a processor, implement the steps of the graphics-driven debugging method described above. For example, the non-transitory computer readable storage medium may be the memory 1132 including program instructions described above that are executable by the processor 1122 of the electronic device 1100 to perform the graphics-driven debugging method described above.
In another exemplary embodiment, a computer program product is also provided, the computer program product comprising a computer program executable by a programmable apparatus, the computer program having code portions for performing the graphics-driven debugging method described above when executed by the programmable apparatus.
The preferred embodiments of the present disclosure have been described in detail above with reference to the accompanying drawings, but the present disclosure is not limited to the specific details of the above embodiments, and various simple modifications may be made to the technical solutions of the present disclosure within the scope of the technical concept of the present disclosure, and all the simple modifications belong to the protection scope of the present disclosure.
In addition, the specific features described in the foregoing embodiments may be combined in any suitable manner, and in order to avoid unnecessary repetition, the present disclosure does not further describe various possible combinations.
Moreover, any combination between the various embodiments of the present disclosure is possible as long as it does not depart from the spirit of the present disclosure, which should also be construed as the disclosure of the present disclosure.
Claims (10)
1. A method of graphics driver debugging, the method comprising:
constructing a debugging accessory of the graphic driver, wherein the debugging accessory is used for storing debugging information of the graphic driver;
acquiring image rendering related information of the graphic driver according to the debugging accessory;
determining fault points of the graphic driver according to the image rendering related information;
The determining the fault point of the graphics driver according to the image rendering related information comprises the following steps:
operating the graphic driver to acquire the difference between the real-time rendering image and the expected rendering image;
determining a pipeline rendering stage at which a fault occurs according to the difference between the real-time rendering image and the expected rendering image;
determining intermediate information in the processing process of a processing unit corresponding to the pipeline rendering stage according to the pipeline rendering stage where the fault occurs;
according to the intermediate information, rendering related information of the real-time rendering image is obtained;
and the rendering related information is put into the debugging accessory, and the fault point of the graphic driver is determined according to the debugging accessory.
2. The graphics-driven debugging method of claim 1, wherein building a graphics-driven debugging accessory comprises:
defining an accessory object of the debug accessory;
defining a parameter object of the debug accessory;
declaring the debug accessory;
creating a channel structure of the debug accessory.
3. The method according to claim 1, wherein determining, according to the pipeline rendering stage at which the fault occurs, intermediate information in a processing procedure of a processing unit corresponding to the pipeline rendering stage includes:
Determining unified variables input in the processing process of a processing unit corresponding to the pipeline rendering stage;
determining variable information transferred in a previous stage of the pipeline rendering stage;
and determining intermediate information in the processing process of the processing unit according to the unified variable and variable information transmitted in the last stage of the pipeline rendering stage.
4. The graphics driver debug method according to claim 1, wherein said acquiring rendering related information of the real-time rendered image from the intermediate information comprises:
determining a designated calculation unit according to a specific variable built in the fragment shader;
and determining coordinate values of the window corresponding to the current fragment according to the calculation result of the specified calculation unit.
5. The graphics driver debug method according to claim 4, wherein said obtaining rendering related information of said real-time rendered image from said intermediate information further comprises:
and acquiring rendering related information of the pixel point corresponding to the coordinate value according to the coordinate value of the window corresponding to the current segment.
6. The graphics driver debug method of claim 1, wherein said placing the rendering related information into the debug accessory, determining a failure point of the graphics driver from the debug accessory comprises:
Acquiring the rendering related information by decoding the debug accessory;
and determining the fault point of the graphic driver according to the rendering related information.
7. The graphics driver debug method of claim 1, wherein said placing the rendering related information into the debug accessory, determining a failure point of the graphics driver from the debug accessory comprises:
superposing the debugging accessory on the color accessory, and outputting a debugging graph to a display end;
and determining the fault point of the graphic driver according to the debugging graphic.
8. A graphics-driven debugging device, the debugging device comprising:
the building module is used for building a debugging accessory of the graphic driver, and the debugging accessory is used for storing the debugging information of the graphic driver;
the acquisition module is used for acquiring image rendering related information of the graphic driver according to the debugging accessory;
the determining module is used for determining fault points of the graphic driver according to the image rendering related information;
the determining module comprises a difference obtaining module, a display module and a display module, wherein the difference obtaining module is used for running the graphic driver to obtain the difference between the real-time rendering image and the expected rendering image;
The determining module comprises a rendering stage obtaining module which is used for determining a pipeline rendering stage at which a fault occurs according to the difference between the real-time rendering image and the expected rendering image;
the determining module comprises an intermediate information obtaining module, a processing unit and a processing unit, wherein the intermediate information obtaining module is used for determining intermediate information in the processing process of the processing unit corresponding to the pipeline rendering stage according to the pipeline rendering stage where the fault occurs;
the determining module comprises a rendering related information obtaining module, which is used for obtaining rendering related information of the real-time rendering image according to the intermediate information;
the determining module comprises a fault determining module which is used for placing the rendering related information into the debugging accessory and determining the fault point of the graphic driver according to the debugging accessory.
9. A non-transitory computer readable storage medium having stored thereon a computer program, characterized in that the program when executed by a processor realizes the steps of the method according to any of claims 1-7.
10. An electronic device, comprising:
a memory having a computer program stored thereon;
a processor for executing the computer program in the memory to implement the steps of the method of any one of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311541971.2A CN117274033B (en) | 2023-11-20 | 2023-11-20 | Graphic driving debugging method and device, storage medium and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311541971.2A CN117274033B (en) | 2023-11-20 | 2023-11-20 | Graphic driving debugging method and device, storage medium and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117274033A CN117274033A (en) | 2023-12-22 |
| CN117274033B true CN117274033B (en) | 2024-03-26 |
Family
ID=89201165
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311541971.2A Active CN117274033B (en) | 2023-11-20 | 2023-11-20 | Graphic driving debugging method and device, storage medium and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117274033B (en) |
Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1542167A1 (en) * | 2003-12-09 | 2005-06-15 | Koninklijke Philips Electronics N.V. | Computer graphics processor and method for rendering 3D scenes on a 3D image display screen |
| CN101360007A (en) * | 2007-07-30 | 2009-02-04 | 辉达公司 | Client server system for analysis and performance tuning of remote graphics devices |
| CN102495769A (en) * | 2010-09-30 | 2012-06-13 | 微软公司 | Dynamic virtual device failure recovery |
| CN105122204A (en) * | 2014-03-13 | 2015-12-02 | 华为技术有限公司 | Graphic processing method, guest operating system (os) and guest os system |
| CN108765534A (en) * | 2018-05-24 | 2018-11-06 | 武汉斗鱼网络科技有限公司 | A kind of image rendering method, device, equipment and storage medium |
| JP2020060606A (en) * | 2018-10-04 | 2020-04-16 | キヤノン株式会社 | Image forming apparatus |
| CN111527554A (en) * | 2017-12-28 | 2020-08-11 | 爱惜康有限责任公司 | Cloud-based medical analysis for customization and recommendation to users |
| CN113034339A (en) * | 2020-10-26 | 2021-06-25 | 中国人民解放军92942部队 | Method for improving vibration data transmission bandwidth based on GPU acceleration |
| CN113919220A (en) * | 2021-10-08 | 2022-01-11 | 西安科技大学 | Intelligent fault diagnosis method for rolling bearing driven by vibration image |
| CN115408227A (en) * | 2022-11-01 | 2022-11-29 | 西安芯瞳半导体技术有限公司 | GPU state debugging method and device based on self-research display card and storage medium |
| CN116185743A (en) * | 2023-04-24 | 2023-05-30 | 芯瞳半导体技术(山东)有限公司 | Dual graphics card contrast debugging method, device and medium of OpenGL interface |
| CN116595104A (en) * | 2023-05-04 | 2023-08-15 | 中国安全生产科学研究院 | Visual processing method of mine safety monitoring system |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10049423B2 (en) * | 2013-03-18 | 2018-08-14 | Vmware, Inc. | Graphics processing unit failure recovery |
-
2023
- 2023-11-20 CN CN202311541971.2A patent/CN117274033B/en active Active
Patent Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1542167A1 (en) * | 2003-12-09 | 2005-06-15 | Koninklijke Philips Electronics N.V. | Computer graphics processor and method for rendering 3D scenes on a 3D image display screen |
| CN101360007A (en) * | 2007-07-30 | 2009-02-04 | 辉达公司 | Client server system for analysis and performance tuning of remote graphics devices |
| CN102495769A (en) * | 2010-09-30 | 2012-06-13 | 微软公司 | Dynamic virtual device failure recovery |
| CN105122204A (en) * | 2014-03-13 | 2015-12-02 | 华为技术有限公司 | Graphic processing method, guest operating system (os) and guest os system |
| CN111527554A (en) * | 2017-12-28 | 2020-08-11 | 爱惜康有限责任公司 | Cloud-based medical analysis for customization and recommendation to users |
| CN108765534A (en) * | 2018-05-24 | 2018-11-06 | 武汉斗鱼网络科技有限公司 | A kind of image rendering method, device, equipment and storage medium |
| JP2020060606A (en) * | 2018-10-04 | 2020-04-16 | キヤノン株式会社 | Image forming apparatus |
| CN113034339A (en) * | 2020-10-26 | 2021-06-25 | 中国人民解放军92942部队 | Method for improving vibration data transmission bandwidth based on GPU acceleration |
| CN113919220A (en) * | 2021-10-08 | 2022-01-11 | 西安科技大学 | Intelligent fault diagnosis method for rolling bearing driven by vibration image |
| CN115408227A (en) * | 2022-11-01 | 2022-11-29 | 西安芯瞳半导体技术有限公司 | GPU state debugging method and device based on self-research display card and storage medium |
| CN116185743A (en) * | 2023-04-24 | 2023-05-30 | 芯瞳半导体技术(山东)有限公司 | Dual graphics card contrast debugging method, device and medium of OpenGL interface |
| CN116595104A (en) * | 2023-05-04 | 2023-08-15 | 中国安全生产科学研究院 | Visual processing method of mine safety monitoring system |
Non-Patent Citations (3)
| Title |
|---|
| Runtime Fault Diagnostics for GPU Tensor Cores;Saurabh Hukerikar等;IEEE;全文 * |
| 基于光源空间透视的平行分割阴影图算法;郭钊;范湘涛;谭剑;;地理与地理信息科学(01期);全文 * |
| 离散制造机加车间三维可视化监控系统;邱枫;刘治红;吴跃;徐曼菲;;机械设计与制造(07期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN117274033A (en) | 2023-12-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108765534B (en) | Image rendering method, device and equipment and storage medium | |
| US7978197B2 (en) | Systems and methods for downloading algorithmic elements to a coprocessor and corresponding techniques | |
| CN108765539B (en) | OpenGLES-based image rendering method, device, equipment and storage medium | |
| CN115145778B (en) | Method and device for analyzing rendering result of display card and storage medium | |
| US7661093B2 (en) | Method and system for assessing performance of a video interface using randomized parameters | |
| CN113342703B (en) | Rendering effect real-time debugging method and device, development equipment and storage medium | |
| CN110287106B (en) | Method and device for debugging shader code, electronic equipment and storage medium | |
| GB2473682A (en) | Outputting the state of a tile based deferred rendering processor | |
| CN111831573A (en) | Method, device, computer system and medium for determining code branch coverage condition | |
| CN116185743B (en) | Dual graphics card contrast debugging method, device and medium of OpenGL interface | |
| CN112732576A (en) | Automatic testing method, device and equipment based on user interface | |
| CN115408227A (en) | GPU state debugging method and device based on self-research display card and storage medium | |
| CN113393585B (en) | Rendering problem positioning method and device, positioning equipment and storage medium | |
| CN109634611B (en) | Mobile terminal three-dimensional model ply file analysis and display method based on OpenGL | |
| CN117274033B (en) | Graphic driving debugging method and device, storage medium and electronic equipment | |
| CN112463139B (en) | Programming method and device based on electronic building blocks, electronic equipment and storage medium | |
| US20120106930A1 (en) | Shared surface hardware-sensitive composited video | |
| US20150121051A1 (en) | Kernel functionality checker | |
| WO2020073200A1 (en) | Program debugging method and system | |
| CN112765018B (en) | Instrument and meter debugging system and method | |
| CN115591243A (en) | Rendering channel performance detection method and device, electronic equipment and storage medium | |
| US9691117B2 (en) | External validation of graphics pipelines | |
| CN111538657B (en) | Page overdrawing detection method and device, electronic equipment and readable medium | |
| CN113391811B (en) | Function compiling method, function compiling device, electronic equipment and computer readable storage medium | |
| CN111930418B (en) | Diagnostic device function configuration method, diagnostic device, and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |