Video card information monitoring system, server, monitoring method and storage medium

Abstract

The invention discloses a video card information monitoring system, a server, a monitoring method and a storage medium. Comprising a graphics card and a substrate management controller, the display card comprises a command register, a data register and a processor; the baseboard management controller generates a request instruction containing a first type of operation codes and at least one parameter according to a monitoring demand, sends the request instruction to the command register, reads a status bit from the command register, and reads data from the data register or writes the data according to the request instruction; the command register receives a request instruction sent by the substrate management controller, stores an operation code, a parameter and a status bit, and feeds the status bit back to the substrate management controller; the processor analyzes and executes the request instruction in the command register, and updates the status bit in the command register; the data register stores data written by the baseboard management controller or the processor and allows the baseboard management controller or the processor to read the data, and the problem that the number of monitorable information is limited due to I2C address limitation is solved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a graphics card information monitoring system, server, monitoring method, and storage medium. Background Art

[0002] In related technologies, physical information is generally obtained through monitoring sensors on the graphics card side, and registers are used to store real-time data. The graphics card information is monitored by directly reading the register address through I2C (Inter-Integrated Circuit). However, the I2C address limits the amount of accessible monitoring information. In existing solutions, each piece of monitoring information needs to be directly bound to the physical address of a specific register. The I2C standard uses a 7-bit address mode and theoretically supports 128 addresses. However, because some addresses are reserved by the protocol, the actual number of available addresses is even smaller. In the graphics card monitoring scenario, if each sensor requires an independent address (for example, temperature, voltage, and power consumption sensors each occupy an address), when the amount of monitoring information increases, the address resources are quickly exhausted. Therefore, the direct binding of the existing hardware address space to the amount of monitoring information limits the amount of information that can be monitored. Summary of the Invention

[0003] The present application provides a graphics card information monitoring system, server, monitoring method, and storage medium. By setting command registers and data registers on the graphics card side and introducing a request instruction design of a first-class opcode and parameter combination, hardware resource dependence is converted into a software-scalable instruction set, thereby solving the limitation of address resources on the amount of monitoring information.

[0004] In a first aspect, the present application provides a graphics card information monitoring system, including a graphics card and a baseboard management controller;

[0005] The graphics card includes command registers, data registers and processors;

[0006] The baseboard management controller is configured to generate a request instruction including a first type of operation code and at least one parameter according to monitoring requirements, send the request instruction to the command register and read the status bit from the command register, and read data from or write data to the data register according to the request instruction;

[0007] The command register is configured to receive a request instruction sent by the baseboard management controller, store a first type of operation code, parameters and status bits, and feed the status bits back to the baseboard management controller;

[0008] The processor is configured to parse and execute a requested instruction in the command register and update a status bit in the command register;

[0009] The data register is configured to store data written by the baseboard management controller or the processor and configured to be read by the baseboard management controller or the processor;

[0010] The first type of operation code is used to identify the type of the request instruction, and the parameter is used to identify the operation object corresponding to the request instruction.

[0011] In a second aspect, the present application also provides a server, including the graphics card information monitoring system in the first aspect.

[0012] In a third aspect, the present application further provides a graphics card information monitoring method, which is applied to a baseboard management controller, comprising:

[0013] Generate a request instruction including a first type of operation code and at least one parameter according to monitoring requirements, and send the request instruction to a command register of a graphics card;

[0014] Get the status bit returned by the graphics card's command register, which indicates the execution status of the graphics card's processor parsing and executing the requested instruction in the command register;

[0015] Read or write data from the graphics card's data register according to the request instruction;

[0016] The first type of operation code is used to identify the type of the request instruction, and the parameter is used to identify the operation object corresponding to the request instruction.

[0017] In a fourth aspect, the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein when the computer program is executed by a processor, the steps of the graphics card information monitoring method in the third aspect are implemented.

[0018] The present application sets up a command register and a data register in the graphics card. The command register is used for request instruction transmission and status synchronization functions, and stores the first type of opcode, parameters and status bits. The data register serves as a general data channel, and monitoring data is exchanged through the data register. The baseboard management controller can generate a request instruction containing the first type of opcode and at least one parameter according to the monitoring requirements. By introducing the design of the request instruction that combines the first type of opcode and parameters, the physical address and the monitoring parameter are decoupled, solving the limitation of the address resource on the amount of monitoring information. After the baseboard management controller writes the request instruction, the graphics card processor can parse and command the request instruction in the register, and update the status bit in the command register to notify the baseboard management controller to read the result, forming a closed-loop control process. Traditional I2C requires an independent address to be assigned for each piece of monitoring information, but the present application uses the logical mapping of the first type of opcode + parameter, and only requires the command register and data register to access massive monitoring information, thus solving the address resource bottleneck problem. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0020] Figure 1 This is an architecture diagram of a graphics card information monitoring system provided by an embodiment of the present application;

[0021] Figure 2 A physical connection diagram of a graphics card information monitoring system provided in an embodiment of the present application;

[0022] Figure 3 This is an architectural diagram of another graphics card information monitoring system provided in an embodiment of the present application;

[0023] Figure 4 This is an architectural diagram of another graphics card information monitoring system provided in an embodiment of the present application;

[0024] Figure 5 A schematic diagram of the structure of a temperature control circuit provided in an embodiment of the present application;

[0025] Figure 6 A schematic diagram of a temperature monitoring architecture after driver loading is completed provided in an embodiment of the present application;

[0026] Figure 7 This is an architectural diagram of another graphics card information monitoring system provided in an embodiment of the present application;

[0027] Figure 8 This is a flow chart of a graphics card information monitoring system provided by an embodiment of the present application;

[0028] Figure 9 This is an architectural diagram of another graphics card information monitoring system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0029] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0030] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0031] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0032] The embodiment of the present application provides a graphics card information monitoring system, Figure 1 This is an architecture diagram of a graphics card information monitoring system provided by an embodiment of the present application. Figure 1 As shown, the graphics card information monitoring system includes a graphics card 10 and a baseboard management controller 20.

[0033] The graphics card 10 includes a command register 11 , a data register 12 and a processor 13 .

[0034] The baseboard management controller 20 is configured to generate a request instruction including a first type of operation code and at least one parameter according to monitoring requirements, send the request instruction to the command register 11 and read the status bit from the command register 11, and read or write data from the data register 12 according to the request instruction.

[0035] In the embodiment of the present application, a command register 11 and a data register 12 are set in the graphics card. The baseboard management controller 20 can communicate with the command register 11 and the data register 12 of the graphics card 10 through I2C, for example. Figure 2 This is a physical connection diagram of a graphics card information monitoring system provided in an embodiment of the present application. Figure 2As shown, the command register 11 is configured to receive a request instruction sent by the baseboard management controller 20, store a first-class opcode, parameters and status bits, and feed back the status bits to the baseboard management controller 20. The baseboard management controller 20 can generate a request instruction containing a first-class opcode and at least one parameter according to monitoring requirements. The baseboard management controller 20 can, for example, send the command register 11 of the graphics card through the SMBus (System Management Bus) interface. SMCLK represents the clock signal, and SMDAT represents the data signal. By setting different first-class opcodes and parameters, specific parameters that need to be read or written are indicated. The range of accessible monitoring information is expanded by combining the first-class opcodes and parameters. Among them, the first-class opcode is used to identify the type of request instruction, and the parameter is used to identify the operation object corresponding to the request instruction.

[0036] Taking a 32-bit command register as an example, the command register has dual-port access capabilities, allowing it to simultaneously receive instruction writes from the baseboard management controller and parse and read data from the processor. Its internal storage space can be divided into an opcode field, a parameter field, and a status bit field. The data format specification for the command register can be, for example, the format shown in Table 1. It should be noted that the command register 11 can also contain opcodes identifying other instructions in addition to the first category of opcodes, so opcodes are uniformly represented in Table 1.

[0037] In Table 1, Bit indicates the bit range, Access indicates the access permission, Default indicates the default value, Description indicates the description, and R / W indicates readable and writable.

[0038] Command Execute represents the command execution bit, which is used to indicate whether the request instruction is executed. When set to 1, it indicates that the corresponding request instruction is executed; when set to 0, it may indicate that the request instruction is waiting for execution or is in an inactive state. Copy represents the copy bit, which can be used to copy related data or operations in specific operations or extended functions. Reserved represents the reserved bit, which is usually used for possible future function expansion. Status represents the status bit, which is used to indicate the execution status of the request instruction. For example, the baseboard management controller waits for the return status bit to be 0x1F to indicate that the execution status of the request instruction is successful. Different status codes may represent different execution results of the request instruction. Table 1 exemplifies two parameters, namely parameter 1 and parameter 2. Parameter 1 is used to pass the first parameter related to the request instruction, and together with parameter 2, it cooperates with the operation code to implement different functions. Parameter 2 is used to pass the second parameter related to the request instruction. The specific meaning depends on the type represented by the operation code.

[0039] Table 1

[0040] Bit Access Default Description 31:31 R / W 0 Command Execute 30:30 0 Copy 29:29 R / W 0 Reserved 28:24 R / W 0 Status 23:16 R / W 0 Parameter 2 15:8 R / W 0 Parameter 1 7:0 R / W 0 Opcode

[0041] The processor 13 is configured to parse and execute the request instruction in the command register 11 and update the status bit in the command register 11. The processor 13 parses the request instruction in the command register and performs corresponding operations according to the request instruction, such as preparing and providing the data to be read to the data register during a read operation, setting parameters according to the data in the data register during a set operation, and updating the status bit in the command register.

[0042] The data register 12 is configured to store data written by the baseboard management controller 20 or the processor 13, and is configured to read data from the baseboard management controller 20 or the processor 13. Taking the data register as 32 bits as an example, the data format specification of the data register can be, for example, the format of Table 2:

[0043] Table 2

[0044]

[0045]

[0046] In Table 2, "Bit" indicates the bit range, "Access" indicates the access permission, "Default" indicates the default value, "Description" indicates the description, and "R / W" indicates read / write access. "Data, 32-bit input / output data" indicates that this data register is used to store 32-bit input / output data.

[0047] This application decouples the physical address from the monitoring parameters by introducing the design of first-class opcodes and parameterized requests. The request instruction sent by the baseboard management controller contains the first-class opcodes and parameters, rather than directly accessing the fixed register address. For example, the first-class opcode can be defined as 0x01 to read temperature and 0x02 to read voltage, and the parameters can specify the specific sensor number. The graphics card processor dynamically parses and executes the request instruction, and updates the status bit in the command register to notify the baseboard management controller to read the result, forming a closed-loop control process. This application converts hardware resource dependencies into a software-scalable instruction set. The amount of monitorable information is determined by the combination of the first-class opcode and the parameters, which solves the problem of limited amount of monitoring information due to I2C address limitations in the prior art, and provides a scalable solution for high-density monitoring scenarios.

[0048] In some optional implementations, the graphics card may further include a capability set register. Figure 3 This is another architecture diagram of a graphics card information monitoring system provided in an embodiment of the present application. Figure 3As shown, capability set register 14 is configured to define the graphics card's support status for a requested instruction. The bits of capability set register 14 are bound to the first-category opcode and parameters of the requested instruction through a predefined mapping relationship. Each bit of the capability set register is bound to a specific first-category opcode and parameter, forming a predefined mapping relationship.

[0049] The baseboard management controller 20 sends a query instruction to the capability set register 14 before sending a request instruction to the command register 11. The capability set register 14 is used to define the graphics card's support status for the request instruction. Setting it to 1 means that out-of-band monitoring is supported, and setting it to 0 means that monitoring records are not supported. Before performing actual parameter queries, check the capability set register 14 to confirm whether it is supported. The capability set register returns the support status corresponding to the request instruction to the baseboard management controller based on the query instruction. If the support status corresponding to the request instruction is support for monitoring, the baseboard management controller responds to the support status corresponding to the request instruction as support for monitoring, and executes the operation of sending the request instruction to the command register. Table 3 provides a design example of a capability set register. Multi-Dword bitmap definition, each Dword (32 bits) represents a type of monitoring capability, and each bit represents the support status of a specific monitoring item (1 = support, 0 = not support). For example: Dword (0): basic monitoring items (temperature, power consumption, memory utilization, etc.), Dword (1): device information (manufacturer, model, firmware version), Dword3: advanced functions (ECC status, reset status, etc.), and the support status of the requested instruction is queried through the first type of operation code (Op) + parameter (Arg1).

[0050] Table 3

[0051] Capability Set Register Recording Parameters Opcode Dword(1)Bit1 Manufacturer Op 0x05,Arg1 0x09 Dword(1)Bit10 model Op 0x05,Arg1 0x0a Dword(1)Bit10 FW version Op 0x05, Arg1 0x08 Dword(1)Bit10 Serial number Op 0x05,Arg1 0x02 Dword(0)Bit2 Temperature (℃) Op 0x02, Arg1 0x00 Dword(0)Bit 16 Power consumption (W) Op 0x04, Arg1 0x00 Dword(1)Bit 28 Power consumption (W) Op 0x1B Dword(4)Bit 4 Video memory utilization Op 0x10 Arg1 0x0A Dword(1)Bit 23 ECC Status Op 0x18, Arg1 0x0 Dword(3)Bit 24 Reset state Op 0x18, Arg1 0x1

[0052] The baseboard management controller cannot predict which request instructions the graphics card supports. For request instructions that the graphics card does not support, the baseboard management controller may return errors or invalid data when sending request instructions, affecting efficiency and reliability. In addition, if the baseboard management controller initiates a request instruction that the graphics card does not support, it must go through a complete I2C transaction before receiving an error response. This application defines the support status of the request instruction defined by the graphics card by setting the capability set register. Before performing the actual parameter query, the capability set register is checked to confirm whether it is supported. By pre-querying the capability set register, the number of invalid communications can be reduced, invalid operations can be avoided, and efficiency can be improved.

[0053] In some optional implementations, the graphics card of the embodiment of the present application may further include a power management controller and / or a register controller.

[0054] Some existing design solutions require information monitoring after the graphics card driver is loaded, and some design solutions also require information monitoring before the graphics card driver is loaded. However, the existing solutions cannot provide a judgment on whether the graphics card driver has been loaded. Based on the above problems, the graphics card of the embodiment of the present application may also include a power management controller. Figure 4 As shown, the baseboard management controller 20 sends a drive status bit query instruction to the command register 11. The drive status bit query instruction includes a specific second type operation code, which is used to uniquely identify the drive status bit query instruction.

[0055] After the command register 11 receives the driver status bit query instruction, the processor 13 will parse it. When it is identified as a driver status bit query instruction, the processor 13 will interact with the power management controller 15. The power management controller 15 is responsible for managing the power supply of the graphics card and monitoring the loading status of the graphics card driver. The power management controller can use the voltage changes in the graphics card as a basis for judging before and after the driver is loaded. The power management controller 15 provides the current driver status bit information to the processor 13. The processor 13 stores the driver status bit read from the power management controller 15 in the data register 12. The baseboard management controller 20 reads the driver status bit from the data register, and then generates a request instruction containing a first type of opcode and at least one parameter based on the status value of the driver status bit and the monitoring requirements, and sends it to the command register of the graphics card. The status value of the driver status bit has different meanings. For example, 0 means that the graphics card driver has not been loaded, and 1 means that the graphics card driver has been loaded.

[0056] In response to the need to monitor information after the graphics card driver is loaded, when the status value of the driver status bit read by the baseboard management controller 20 indicates that the graphics card driver has been loaded (the status value is 1), the baseboard management controller 20 can then execute the operation of sending a request instruction to the command register 11. If the status value indicates that the graphics card driver has not been loaded (the status value is 0), the baseboard management controller 20 can, for example, wait for a period of time before querying again, or adopt other error handling strategies. In response to the need to monitor information before the graphics card driver is loaded, the status value of the driver status bit read by the baseboard management controller 20 indicates that the graphics card driver has not been loaded. A corresponding request instruction containing a first type of operation code and at least one parameter can also be generated according to the monitoring requirements and sent to the command register of the graphics card.

[0057] like Figure 4As shown, if the graphics card further includes a register controller 16, the baseboard management controller 20 is configured to send a communication status bit query instruction to the command register 11 before sending a request instruction to the command register 11. The communication status bit query instruction includes a third-category opcode. The third-category opcode is used to identify the communication status bit query instruction. The processor is configured to parse and execute the communication status bit query instruction in the command register, read the communication status bit from the register controller, and store it in the data register. The baseboard management controller reads the communication status bit from the data register and, in response to the status value of the communication status bit indicating normal communication, executes the operation of sending the request instruction to the command register.

[0058] In traditional solutions, the baseboard management controller directly sends request instructions to the graphics card. This lacks pre-judgment of the communication link status and may lead to problems such as bus conflicts, invalid instruction transmission, and frequent retries of invalid instructions. The embodiment of the present application adds a communication status pre-query mechanism. Before sending a request instruction, the baseboard management controller first sends a communication status bit query instruction carrying a third-class opcode, parses the communication status bit in the data register, and decides whether to trigger the sending of subsequent request instructions based on the status value. The embodiment of the present application provides a low-latency, high-robustness solution for graphics card information monitoring by deeply coupling the communication status monitoring of the register controller with the instruction sending logic of the baseboard management controller.

[0059] In some optional implementations, a temperature control circuit may be provided in the processor, and the temperature control circuit is configured to collect temperature data and store it in a data register.

[0060] The baseboard management controller is configured to indicate that the driver loading is not complete based on the status value of the driver status bit, generate a first temperature monitoring request instruction including a first type of operation code and at least one parameter according to the monitoring requirements, send it to the command register of the graphics card, and read the temperature data collected and stored by the temperature control circuit integrated in the processor from the data register.

[0061] The embodiment of the present application integrates a temperature control circuit into the processor of the graphics card, which can realize temperature monitoring before the driver loading is completed, and then realize the core temperature detection and overheating protection functions. Temperature monitoring before the driver loading is completed provides the system with a key early warning capability, avoiding hardware loss caused by heat dissipation lag. The embodiment of the present application fills the monitoring blind spot of the traditional monitoring solution before the driver loading is completed by deeply integrating the temperature control circuit into the processor hardware and designing it to be independent of the access path, and realizes the full life cycle temperature coverage from graphics card power-on to full load operation, providing key technical support for the reliability design of high-performance computing equipment.

[0062] Figure 5 A schematic diagram of a temperature control circuit according to an embodiment of the present invention is shown in FIG. Figure 5As shown, the temperature control circuit includes a resistor R1, a thermistor RT1, and a controller. Resistor R1 and thermistor RT1 are connected in series between the power supply terminal VCC and the ground terminal GND. The controller collects the voltage at the connection node between resistor R1 and thermistor RT1 and determines the temperature based on the collected voltage. The controller can be, for example, an MCU (Microcontroller Unit) with an ADC (Analog-to-Digital Converter) sampling device. Thermistor RT1 can also be connected in parallel with capacitor C1 to filter out high-frequency interference signals from the power supply or circuit board induction.

[0063] In some optional implementations, the graphics card may further include multiple temperature sensors, which are respectively disposed at various components of the graphics card to collect temperature data and store the data in a data register after being calculated by a processor.

[0064] The baseboard management controller is configured to indicate that the driver loading is completed based on the status value of the driver status bit, generate a second temperature monitoring request instruction including a first type of operation code and at least one parameter according to the monitoring requirements, send it to the command register of the graphics card, and read the temperature data collected and stored by each temperature sensor from the data register.

[0065] After the driver is loaded, the graphics card temperature needs to be obtained depending on the application load. This application monitors the temperature sensed by multiple temperature sensors installed at various components of the graphics card. Multiple temperature sensors are installed at various components of the graphics card. Figure 6 This is a schematic diagram of a temperature monitoring architecture after the driver loading is completed provided in the embodiment of the present application. Figure 6 As shown, six temperature sensors are exemplarily provided, one each on the graphics card's processor, video memory, power supply module, PCB (Printed Circuit Board), heat sink, and air inlet. The graphics card's processor 13 calculates the temperature collected by each temperature sensor, for example, using the maximum or average temperature as the graphics card's temperature, and transmits it to the data register 12 for storage.

[0066] After the driver is loaded, this application uses the fusion of multiple temperature sensors to fully capture the temperature distribution to prevent local overheating (such as hot spots in the video memory or power supply module) from being missed. Before the driver is loaded, it relies on hardware-level temperature control circuits (not software drivers) to ensure the physical authenticity of the temperature data during the initialization phase. After the driver is loaded, it uses multi-source data aggregation to avoid misjudgments caused by failure or errors of a single temperature sensor.

[0067] In some optional embodiments, the graphics card may further include a configuration register. The configuration register is used to capture link status and error information and store it in the data register. The baseboard management controller is configured to send a link status and error information monitoring request instruction to the command register and read the link status and error information captured and stored in the configuration register from the data register.

[0068] Figure 7 This is another architecture diagram of a graphics card information monitoring system provided in an embodiment of the present application. Figure 7 As shown, the graphics card includes a configuration register 17. Configuration register 17 is responsible for capturing the graphics card's link status and error information and storing this information in data register 12. Based on monitoring requirements, the baseboard management controller 20 generates a link status and error information monitoring request instruction. This instruction contains a specific first-class opcode indicating a link status and error information monitoring request. The baseboard management controller 20 sends the generated instruction to the graphics card's command register. The processor parses the link status and error information monitoring request instruction in the command register, and the configuration register begins operating, capturing the graphics card's link status (such as the PCIe link's connection status and bandwidth usage) and possible error information (such as link timeout errors and data transmission errors) in real time. The configuration register stores the captured link status and error information in the data register. The baseboard management controller reads the link status and error information captured and stored in the configuration register from the data register. The baseboard management controller analyzes and processes the read information. For example, if a link status anomaly or error information is detected, the baseboard management controller can trigger a corresponding alarm mechanism, such as sending an alarm message to the system management interface or sounding an alarm through a buzzer.

[0069] The embodiments of the present application capture the link status and error information of the graphics card in real time through the configuration register. The baseboard management controller can obtain this information in a timely manner, so that it can respond quickly when problems arise. For example, when a link timeout error occurs, the baseboard management controller can immediately detect it and take appropriate measures, such as attempting to re-establish the link or notifying the user to check. The configuration register stores the captured information in a unified data register, making it convenient for the baseboard management controller to read and analyze it. This centralized management method makes the management of link status and error information more orderly, and facilitates a comprehensive evaluation of the performance and stability of the graphics card.

[0070] In some embodiments, as Figure 7As shown, the configuration registers may include, for example, a PCIE (Peripheral Component Interconnect Express) configuration register 171 and an AER (Advanced Error Reporting) register 172. The PCIE configuration register is used to record status information of the graphics card PCIE link, including the number of times the link enters the recovery state from the L0 state, the number of replay flips issued by the graphics card on the PCIE link, and the number of NAKs (Negative Acknowledgements) issued by the Host RC (Host Root Complex) on the PCIE link.

[0071] The AER register is used to record the error type of UCE (Uncorrectable Error) errors reported by the graphics card, distinguishing between non-fatal and fatal errors. The graphics card continuously monitors the various status bits in the PCIE configuration register. For example, the hardware logic circuit counts the number of times the link enters the recovery state from the L0 state and records it in bits 31:24 of the 32-bit data; counts the number of replay flips issued by the graphics card on the PCIE link and records it in bits 15:0; and counts the number of NAKs issued by the HostRC on the PCIE link and records it in bits 31:16.

[0072] When a UCE error occurs on the graphics card, the AER register records the error type. For non-fatal errors, such as data link layer protocol errors or receipt of an abnormally erroneous TLP (Transaction Layer Packet), the error count is recorded in bits 15:8 of the 32-bit data. Fatal errors, such as receipt of a poisoned TLP, are recorded in bits 23:16. The link rate is also recorded in bits 2:0, and the link bandwidth in bits 6:4.

[0073] An embodiment of the present application also provides a server, including the graphics card information monitoring system in any embodiment of the present application.

[0074] For descriptions of features in the embodiment corresponding to the server, please refer to the relevant descriptions of the embodiment corresponding to the graphics card information monitoring system, which will not be repeated here.

[0075] The embodiment of the present application provides a method for monitoring graphics card information. Figure 8 This is a flowchart of a graphics card information monitoring system provided in an embodiment of the present application. The graphics card information monitoring method provided in an embodiment of the present application can be applied to a baseboard management controller. Figure 8This is a flowchart of a method for monitoring graphics card information according to an embodiment of the present application. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here. Figure 8 As shown, the graphics card information monitoring method provided by this application includes:

[0076] S110: Generate a request instruction including a first type of operation code and at least one parameter according to monitoring requirements, and send the request instruction to a command register of a graphics card.

[0077] The baseboard management controller can generate a request instruction based on specific monitoring requirements. The request instruction includes a first-class opcode and at least one parameter. The first-class opcode is used to identify the type of the request instruction, and the parameter is used to identify the operation object corresponding to the request instruction. By setting different first-class opcodes and parameters, the specific parameters that need to be read or written are indicated. The range of accessible monitoring parameters is expanded by the combination of first-class opcodes and parameters. The baseboard management controller writes the request instruction including the first-class opcode and at least one parameter into the command register of the graphics card. The command register of the graphics card integrates the opcode (for example, bits 7:0), parameter 1, parameter 2 (for example, parameter 1 is bits 15:8, parameter 2 is bits 23:16), and status feedback bits (for example, bits 28:24), supporting command interaction between the baseboard management controller and the graphics card.

[0078] S120: Obtain a status bit returned by the command register of the graphics card, where the status bit indicates an execution status of the graphics card processor parsing and executing the request instruction in the command register.

[0079] S130 , reading data from or writing data into a data register of the graphics card according to a request instruction.

[0080] After the graphics card processor 13 parses and executes the request instruction in the command register 11, it will update the status bit in the command register 11. The baseboard management controller can know the execution status of the request instruction through the status bit returned by the command register of the graphics card. The baseboard management controller reads or writes data from the data register of the graphics card according to the request instruction, forming a closed-loop control process.

[0081] In the embodiment of the present application, the baseboard management controller can generate a request instruction including a first-class opcode and at least one parameter according to the monitoring requirements. By introducing the design of the request instruction of the first-class opcode and parameter combination, the physical address is decoupled from the monitoring parameters, and the limitation of the address resources on the number of monitoring parameters is solved. After the baseboard management controller writes the request instruction, the processor of the graphics card can parse and command the request instruction in the register, and update the status bit in the command register to know the execution status of the request instruction. According to the request instruction, the baseboard management controller reads data from or writes data to the data register of the graphics card to form a closed-loop control process. The present application converts hardware resource dependence into a software-scalable instruction set. The amount of monitoring information is determined by the combination of the first-class opcode and the parameter, which solves the problem of the I2C address limitation in the prior art that the amount of monitoring information is limited, and provides a scalable solution for high-density monitoring scenarios.

[0082] In some optional implementations, reading data from or writing data to a data register of a graphics card according to a request instruction includes:

[0083] Based on the request instruction being a read operation, after obtaining the status bit returned by the command register of the graphics card, the monitoring data corresponding to the request instruction is read from the data register of the graphics card;

[0084] or,

[0085] Based on the request instruction being a setting operation, before sending the request instruction to the command register of the graphics card, configuration data corresponding to the setting operation is written to the data register of the graphics card.

[0086] The request instruction in the embodiment of the present application may be, for example, a read operation or a set operation.

[0087] For read operations, the baseboard management controller writes the corresponding first-class opcode and parameters to the command register based on the desired parameter (such as temperature or firmware version). For example, bits 28-24 of the command register are set to the status code, which the graphics card processor updates after processing the request. 0x1F is the predefined "request successfully received" status code, indicating that the graphics card is ready to return data. The baseboard management controller queries the status by reading the command register and determines that the request is successful when 0x1F is detected. It then reads the monitoring data corresponding to the request from the data register.

[0088] For setup operations, the baseboard management controller (BMC) first writes the configuration data corresponding to the setup operation to the graphics card's data register before sending a request command to the graphics card's command register. For example, if you want to set a graphics card parameter (such as fan speed or graphics card frequency), the BMC will write the corresponding parameter value to the data register. This is done to prepare the data to be set in advance so that the graphics card processor can directly process the data based on the request command received by the command register.

[0089] After the baseboard management controller writes the configuration data corresponding to the setup operation into the data register, it then writes the corresponding request instruction into the command register. This request instruction contains information such as the first-class opcode and parameters, which are used to instruct the graphics card's processor to perform a specific operation. For example, the first-class opcode may indicate "set fan speed," while the parameters specify the specific speed value. By writing the request instruction into the command register, the baseboard management controller triggers the graphics card's processor to process the configuration data previously written into the data register.

[0090] In some optional implementations, before sending the request instruction to the command register of the graphics card, the method further includes:

[0091] Send a query command to the graphics card's capability set register;

[0092] Get the graphics card's capability set register based on the support status of the request instruction returned by the query instruction;

[0093] In response to the support status corresponding to the request instruction being support monitoring, an operation of sending the request instruction to the command register of the graphics card is executed.

[0094] Before sending a request instruction to the command register, the baseboard management controller will first send a query instruction to the capability set register. The query instruction contains the first type of operation code and parameter information of the request instruction to be sent.

[0095] When the baseboard management controller receives the support status returned by the capability set register, it will make a judgment. If the support status indicates that monitoring is supported (that is, the corresponding bit is 1), it will execute the operation of sending a request instruction to the command register. If the support status indicates that monitoring is not supported (that is, the corresponding bit is 0), it will not send the request instruction to the command register, but will choose to record error information or take other error handling measures.

[0096] The baseboard management controller of the embodiment of the present application first queries the capability set register before sending a request instruction, and sends a request instruction when it determines that the graphics card supports the instruction, thereby avoiding sending unsupported request instructions to the graphics card, reducing invalid communication operations, and improving the communication efficiency of the system.

[0097] In some optional implementations, before sending the request instruction to the command register of the graphics card, the method further includes:

[0098] Receive graphics card initialization completion information sent by the system BIOS storage device.

[0099] In some information monitoring, the graphics card must be powered on and initialized before monitoring can be performed. However, existing graphics card information monitoring lacks an identification bit, making it impossible to determine whether the graphics card has been initialized out-of-band. The present embodiment of the application determines whether the graphics card has been initialized by receiving graphics card initialization completion information sent by the system BIOS storage device before sending a request instruction to the graphics card's command register.

[0100] Optional, such as Figure 9As shown in the figure, after the graphics card is powered on, the graphics card's BIOS (Basic Input / Output System) storage device (also known as the VBIOS) takes over initialization, and the VBIOS performs self-tests. The graphics card initialization process primarily involves configuring the graphics card's configuration registers after the graphics card is powered on. The VBIOS contains the basic instructions required to initialize and configure the graphics card hardware, including setting the default clock frequency, memory configuration, and display mode. Furthermore, the VBIOS is responsible for providing a basic graphics environment so that the operating system and driver can take over and further configure the graphics card. The system BIOS participates in the graphics card initialization process. Its main actions include assigning a BUS number, performing link training, and configuring registers. Before handing over the graphics card to the operating system, the system BIOS sends relevant information such as the system's CPU (Central Processing Unit), MEM (Memory), PCIE (Peripheral Component Interconnect Express), HDD (Hard Disk Drive), MAC (Media Access Control Address), and BIOS / ME FW (Basic Input / Output System / Management Engine Firmware) to the baseboard management controller (BMC) via OEM IPMI (Original Equipment Manufacturer Intelligent Platform Management Interface Commands). After the system BIOS completes the graphics card configuration settings, it notifies the BMC via IPMI commands. The BMC can use this information to determine that graphics card initialization is complete.

[0101] In some optional implementations, before generating a request instruction including a first-category opcode and at least one parameter according to monitoring requirements and sending the request instruction to a command register of a graphics card, the method further includes:

[0102] Sending a driver status bit query instruction to the command register of the graphics card, the driver status bit query instruction including a second type of operation code; the second type of operation code is used to identify the driver status bit query instruction;

[0103] Read the driver status bit of the graphics card's power management controller from the graphics card's data register;

[0104] Correspondingly, generating a request instruction containing a first type of opcode and at least one parameter according to monitoring requirements, and sending it to the command register of the graphics card includes: generating a request instruction containing a first type of opcode and at least one parameter according to the status value of the drive status bit and monitoring requirements, and sending it to the command register of the graphics card.

[0105] The driver status bit is the data that the graphics card processor parses and executes the driver status bit query instruction in the command register, reads the driver status bit from the power management controller and stores in the data register.

[0106] and / or,

[0107] Sending a communication status bit query instruction to the command register of the graphics card, the communication status bit query instruction including a third type of operation code; the third type of operation code is used to identify the communication status bit query instruction;

[0108] Read the communication status bit of the graphics card's register controller from the graphics card's data register;

[0109] In response to the status value of the communication status bit indicating that the communication is normal, an operation of sending a request instruction to the command register of the graphics card is executed; wherein the communication status bit is parsed by the graphics card processor and executes the communication status bit query instruction in the command register, reads the communication status bit from the register controller and stores the data in the data register.

[0110] Some existing design solutions require information monitoring after the graphics card driver is loaded, while some design solutions also require information monitoring before the graphics card driver is loaded. However, existing solutions cannot provide a judgment on whether the graphics card driver has been loaded. Based on the above problems, in an embodiment of the present application, before generating a request instruction containing a first type of opcode and at least one parameter according to the monitoring requirements and sending it to the graphics card command register, it also includes:

[0111] Send a driver status bit query instruction to the graphics card's command register;

[0112] Read the driver status bit of the graphics card's power management controller from the graphics card's data register.

[0113] The driver status bit query instruction includes a second-class opcode; the second-class opcode is used to identify the driver status bit query instruction. After the command register receives the driver status bit query instruction, the processor parses it. If it identifies the driver status bit query instruction, the processor interacts with the power management controller. The power management controller manages the graphics card's power supply and monitors the graphics card driver loading status. The power management controller can use voltage changes in the graphics card as a basis for determining whether the driver has been loaded before and after. The power management controller provides the processor with the current driver status bit information. The processor stores the driver status bit read from the power management controller in the data register. The baseboard management controller reads the driver status bit from the data register and, based on the driver status bit value and monitoring requirements, generates a request instruction containing the first-class opcode and at least one parameter, and sends it to the graphics card's command register. The driver status bit value can have different meanings, for example, 0 indicates that the graphics card driver has not been loaded, and 1 indicates that the graphics card driver has been loaded.

[0114] Correspondingly, generating a request instruction containing a first type of opcode and at least one parameter according to monitoring requirements, and sending it to the command register of the graphics card includes: generating a request instruction containing a first type of opcode and at least one parameter according to the status value of the drive status bit and monitoring requirements, and sending it to the command register of the graphics card.

[0115] The driver status bit is the data that the graphics card processor parses and executes the driver status bit query instruction in the command register, reads the driver status bit from the power management controller and stores in the data register.

[0116] The baseboard management controller can generate a request instruction containing a first type of opcode and at least one parameter based on the status value of the driver status bit and the monitoring requirements. For example, in response to the need to monitor information after the graphics card driver is loaded, when the status value of the driver status bit read by the baseboard management controller indicates that the graphics card driver has been loaded (the status value is 1), the baseboard management controller 20 can generate a request instruction containing a first type of opcode and at least one parameter, and execute the operation of sending the request instruction to the command register 11. If the status value indicates that the graphics card driver has not been loaded (the status value is 0), the baseboard management controller can, for example, wait for a period of time before querying again, or adopt other error handling strategies. In response to the need to monitor information before the graphics card driver is loaded, the status value of the driver status bit read by the baseboard management controller indicates that the graphics card driver has not been loaded. A corresponding request instruction containing a first type of opcode and at least one parameter can also be generated according to the monitoring requirements and sent to the command register of the graphics card.

[0117] In traditional solutions, the baseboard management controller directly sends request instructions to the graphics card, which lacks prejudgment of the communication link status and may cause bus conflicts, invalid instruction transmission, frequent retries of invalid instructions, and other problems. Before generating a request instruction containing a first-class opcode and at least one parameter according to monitoring requirements and sending it to the graphics card's command register, the present application may also include:

[0118] Send a communication status bit query instruction to the graphics card's command register;

[0119] Read the communication status bit of the graphics card's register controller from the graphics card's data register;

[0120] In response to the status value of the communication status bit indicating that the communication is normal, an operation of sending a request instruction to the command register of the graphics card is executed.

[0121] Before sending the request instruction to the command register, the baseboard management controller sends a communication status bit query instruction to the command register. The communication status bit query instruction includes a third-category opcode. The third-category opcode is used to identify the communication status bit query instruction. The graphics card processor parses and executes the communication status bit query instruction in the command register, reads the communication status bit from the register controller, and stores it in the data register. The baseboard management controller reads the communication status bit from the data register and, in response to the status value of the communication status bit indicating normal communication, executes the operation of sending the request instruction to the command register.

[0122] This embodiment of the application adds a new communication status pre-query mechanism. Before sending a request instruction, the baseboard management controller first sends a communication status bit query instruction carrying a third-class opcode, parses the communication status bit in the data register, and decides whether to trigger the subsequent request instruction based on the status value. By deeply coupling the register controller's communication status monitoring with the baseboard management controller's instruction sending logic, this embodiment of the application provides a low-latency, highly robust solution for graphics card information monitoring.

[0123] In some optional implementations, generating a request instruction including a first-category opcode and at least one parameter based on a status value of a driver status bit and a monitoring requirement, and sending the request instruction to a command register of a graphics card includes:

[0124] Based on the status value of the driver status bit indicating that the driver loading is not complete, generating a first temperature monitoring request instruction including a first type of operation code and at least one parameter according to the monitoring requirement, and sending the instruction to the command register of the graphics card;

[0125] Correspondingly, reading data from the data register of the graphics card according to the request instruction includes: reading temperature data collected and stored by the temperature control circuit integrated in the processor of the graphics card from the data register of the graphics card according to the first temperature monitoring request instruction.

[0126] In the embodiment of the present application, the baseboard management controller can indicate that the driver loading is not complete based on the status value of the driver status bit, generate a first temperature monitoring request instruction containing a first type of opcode and at least one parameter according to the monitoring requirements, and send it to the command register of the graphics card, and read the temperature data collected and stored by the temperature control circuit integrated in the processor from the data register. The embodiment of the present application can realize temperature monitoring before the driver loading is not complete, and then realize the core temperature detection and overheating protection functions. Temperature monitoring before the driver loading is completed provides the system with a key early warning capability, avoiding hardware loss caused by heat dissipation lag. The embodiment of the present application fills the monitoring blind spot of the traditional monitoring solution before the driver loading is completed by deeply integrating the temperature control circuit into the processor hardware and designing it independent of the access path, and realizes the temperature coverage of the whole life cycle from graphics card power-on to full load operation, providing key technical support for the reliability design of high-performance computing equipment.

[0127] In some optional implementations, generating a request instruction including a first-category opcode and at least one parameter based on a status value of a driver status bit and a monitoring requirement, and sending the request instruction to a command register of a graphics card includes:

[0128] Based on the status value of the driver status bit indicating that the driver loading is complete, generating a second temperature monitoring request instruction including a first type of operation code and at least one parameter according to the monitoring requirement, and sending the instruction to the command register of the graphics card;

[0129] Correspondingly, reading data from the data register of the graphics card according to the request instruction includes: reading temperature data collected and stored by temperature sensors at various components of the graphics card from the data register of the graphics card according to the second temperature monitoring request instruction.

[0130] After the driver is loaded, it is necessary to obtain the temperature of the graphics card depending on the application load. The present application can monitor the temperature of the graphics card through the temperature sensed by multiple temperature sensors arranged at various components of the graphics card. The baseboard management controller can indicate that the driver loading is complete based on the status value of the driver status bit, generate a second temperature monitoring request instruction containing a first type of opcode and at least one parameter according to the monitoring requirements, and send it to the command register of the graphics card to read the temperature data collected and stored by each temperature sensor from the data register. After the driver is loaded, the present application comprehensively captures the temperature distribution through the fusion of multiple temperature sensors to prevent local overheating from being missed (such as hot spots in the video memory or power supply module). Before the driver is loaded, it relies on the hardware-level temperature control circuit (not software driver) to ensure the physical authenticity of the temperature data in the initialization phase; after the driver is loaded, it uses multi-source data aggregation to avoid misjudgment caused by failure or error of a single temperature sensor.

[0131] In some optional implementations, sending a request instruction to a command register of a graphics card includes: sending a link status and error information monitoring request instruction to a command register of the graphics card;

[0132] Correspondingly, reading data from the data register of the graphics card includes: reading the configuration register of the graphics card from the data register of the graphics card to capture the stored link status and error information.

[0133] Based on monitoring requirements, the baseboard management controller (BMC) can generate a link status and error information monitoring request instruction. This instruction includes a specific first opcode indicating a link status and error information monitoring request. The BMC sends the generated instruction to the graphics card's command register. The processor parses the link status and error information monitoring request instruction in the command register, and the configuration register begins operating to capture the graphics card's link status and any error information in real time. The configuration register stores the captured link status and error information in the data register. The BMC reads the link status and error information captured and stored in the configuration register from the data register, allowing the BMC to analyze and process the information.

[0134] The embodiment of the present application captures the link status and error information of the graphics card in real time by configuring registers. The baseboard management controller can obtain this information in a timely manner, so that it can respond quickly when problems occur.

[0135] In some optional implementations, before sending the request instruction to the command register of the graphics card, the method further includes:

[0136] Send an asynchronous request to the graphics card's command register;

[0137] Write the data corresponding to the asynchronous request to the temporary memory of the graphics card;

[0138] The asynchronous request includes a fourth type of operation code; the fourth type of operation code is used to identify the asynchronous request.

[0139] Correspondingly, obtaining the status bit returned by the command register of the graphics card includes: sending a polling command to the command register of the graphics card, and obtaining the status bit returned by the command register of the graphics card.

[0140] In some solutions, the baseboard management controller (BMC) not only needs to obtain static and status information about the graphics card but also needs to be able to write information out-of-band, such as setting the fan speed of an actively cooled graphics card and modifying the graphics card's frequency, voltage, and power consumption. The BMC is a hardware management unit independent of the host operating system, responsible for monitoring and controlling the hardware (e.g., querying graphics card status and adjusting fan speed) before system boot, when the operating system is not loaded, and during system operation. For complex devices like graphics cards, some operations (e.g., modifying GPU frequency and voltage) require the graphics card driver in the operating system, as the driver controls the underlying hardware control logic (e.g., register configuration and power management policies). Communication between the BMC and the graphics card can only process requests from a single thread at a time and has limited bandwidth. If synchronous communication is used (i.e., after sending a request, the BMC must wait for a response before processing the next request), prolonged blocking can lead to interface resource monopoly, preventing timely response to other urgent requests (e.g., a fan speed command triggered by a temperature threshold). In synchronous mode, the BMC must fully utilize the link after sending a request until the driver completes processing and returns a result. If driver processing takes a long time (such as complex power consumption adjustments that take hundreds of milliseconds or even seconds), the interface cannot process other requests (such as reading graphics card temperature, responding to hardware failure interrupts) during this period, which may cause management delays or functional failures.

[0141] To avoid long-term interface occupancy, this application can asynchronously implement requests that require the graphics driver's participation. Asynchronous processing allows the interface to continue processing other urgent requests while waiting for the graphics driver's response, improving the system's concurrent processing capabilities and response efficiency.

[0142] This application can use a special fourth-category opcode to issue asynchronous requests or polling commands to the graphics card driver. Parameter 1 (Arg1): When the value is between 0x00 and 0xFE, it is used to indicate the specific type of asynchronous request to be issued. Different values correspond to different requests. For example, 0x01 may indicate setting the fan speed, 0x02 indicates modifying the graphics card frequency, and so on. When the value is 0xFF, it indicates that an asynchronous request needs to be polled. Parameter 2 (Arg2): When Arg1 is in the range of 0x00 to 0xFE, Arg2 represents the address offset of the asynchronous request parameters. This means that the relevant request parameters will be stored in a specific memory location, and Arg2 is used to indicate where to start reading these parameters. When Arg1 is 0xFF, Arg2 represents the ID of the asynchronous request to be polled. Each asynchronous request is assigned a unique ID when it is issued, which is used to track the status of the request later.

[0143] The baseboard management controller first sends an asynchronous request to the graphics card's command register. The asynchronous request includes a fourth-category opcode and then writes the corresponding data to the graphics card's scratchpad memory. For example, if the request is to set the fan speed, the target speed and other related parameters are stored in the scratchpad memory. Based on the asynchronous request list, the baseboard management controller encodes the instruction type in Arg1 and includes a pointer to the parameter block in the scratchpad memory in Arg2. It then constructs the request instruction using the first-category opcode and sends it to the command register. Based on the request instruction written to the command register, the graphics card driver processes the instruction according to the type indicated by Arg1 and the parameter information provided by Arg2. Because its response time is uncontrolled, processing may take some time. To monitor the progress of an asynchronous request, the baseboard management controller can set Arg1 to 0xFF, enter the ID of the asynchronous request to be polled in Arg2, and then issue a polling request. By continuously polling, the baseboard management controller can obtain the latest status of the request execution. The baseboard management controller then reads the data register to confirm the parameter value to be modified.

[0144] The status bits returned by polling include, for example:

[0145] SUCCESS: Indicates that the request has been successfully processed synchronously and data is available. The corresponding driver status code is NV_MSGBOX_DATA_ASYNC_REQ_STATUS_SUCCESS.

[0146] ERR_MISC: Indicates that the request failed. You need to check the asynchronous request status code indicated in Data-Out to determine the specific reason.

[0147] ACCEPTED: Indicates that the request has been accepted and will be processed asynchronously.

[0148] ERR_ARG2: Indicates that the request ID in the provided Arg2 does not correspond to an active request. The request ID may be incorrect or the request has expired.

[0149] ERR_AGAIN: Indicates that the system lacks the necessary resources to accept the request, such as insufficient memory, driver busy, etc.

[0150] ERR_BUSY: Indicates that when trying to issue an asynchronous request, another request has already been issued, that is, another asynchronous request is currently being processed.

[0151] In the embodiment of the present application, through asynchronous requests (including the fourth type of opcode), the baseboard management controller can immediately release the interface link after sending the request, without waiting for driver processing. During this period, other tasks (such as polling sensor data and responding to management requests from other devices) can be processed, thereby improving interface utilization. This solves the problem of interface blocking that may be caused by the uncontrolled response time of the graphics card driver when the baseboard management controller writes information out of band, improves the overall performance and response efficiency of the system, and even if the graphics card driver response time is long, it will not affect the processing of other urgent requests, thereby ensuring the stability and reliability of the system.

[0152] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0153] An embodiment of the present application further provides a computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, wherein when the computer program is executed by a processor, the steps of any of the above-mentioned graphics card information monitoring method embodiments are implemented.

[0154] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0155] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned graphics card information monitoring method embodiments are implemented.

[0156] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of any of the above-mentioned graphics card information monitoring method embodiments are implemented.

[0157] Professionals may further appreciate that the modules and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0158] The above is a detailed introduction to the production management method provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A graphics card information monitoring system, characterized in that: include: graphics card and baseboard management controller; The graphics card includes a command register, a data register and a processor; The baseboard management controller is configured to generate a request instruction including a first type of operation code and at least one parameter according to monitoring requirements, send the request instruction to the command register and read a status bit from the command register, and read data from or write data to the data register according to the request instruction; The command register is configured to receive a request instruction sent by the baseboard management controller, store a first-category operation code, a parameter, and a status bit, and feed the status bit back to the baseboard management controller; the processor is configured to parse and execute the request instruction in the command register, and update the status bit in the command register; The data register is configured to store data written by the baseboard management controller or the processor, and configured to allow the baseboard management controller or the processor to read data; The first type of operation code is used to identify the type of the request instruction, and the parameter is used to identify the operation object corresponding to the request instruction.

2. The graphics card information monitoring system according to claim 1, wherein: The graphics card also includes a capability set register; The capability set register is configured to define the graphics card's support status for the requested instruction; the bits of the capability set register are bound to the first type of opcode and parameters of the requested instruction through a predefined mapping relationship; The baseboard management controller is configured to send a query instruction to the capability set register before sending a request instruction to the command register; the capability set register returns a support status corresponding to the request instruction to the baseboard management controller based on the query instruction; In response to the support status corresponding to the request instruction being support monitoring, the baseboard management controller executes an operation of sending a request instruction to the command register.

3. The graphics card information monitoring system according to claim 1, wherein: The graphics card also includes a power management controller; The baseboard management controller is configured to send a drive status bit query instruction to the command register, wherein the drive status bit query instruction includes a second type of operation code; the second type of operation code is used to identify the drive status bit query instruction; the processor is configured to parse and execute the drive status bit query instruction in the command register, read the drive status bit from the power management controller, and store it in the data register; the baseboard management controller generates a request instruction including a first type of operation code and at least one parameter based on the state value of the drive status bit and monitoring requirements, and sends the request instruction to the command register of the graphics card; and / or, The graphics card also includes a register controller; the baseboard management controller is configured to send a communication status bit query instruction to the command register before sending a request instruction to the command register, and the communication status bit query instruction includes a third-category opcode; the third-category opcode is used to identify the communication status bit query instruction; the processor is configured to parse and execute the communication status bit query instruction in the command register, read the communication status bit from the register controller and store it in the data register; the baseboard management controller reads the communication status bit from the data register, and in response to the status value of the communication status bit indicating that the communication is normal, executes the operation of sending a request instruction to the command register.

4. The graphics card information monitoring system according to claim 3, wherein: The processor is provided with a temperature control circuit; the temperature control circuit is configured to collect temperature data and store it in the data register; The baseboard management controller is configured to indicate that driver loading is incomplete based on the status value of the driver status bit, generate a first temperature monitoring request instruction including a first type of opcode and at least one parameter according to monitoring requirements, send it to the command register of the graphics card, and read the temperature data collected and stored by the temperature control circuit integrated in the processor from the data register.

5. The graphics card information monitoring system according to claim 3, wherein: The graphics card further includes a plurality of temperature sensors, which are respectively provided at respective components of the graphics card and are used to collect temperature data, and store the temperature data in the data register after being calculated by the processor; The baseboard management controller is configured to indicate that driver loading is complete based on the status value of the driver status bit, generate a second temperature monitoring request instruction including a first type of operation code and at least one parameter according to monitoring requirements, send it to the command register of the graphics card, and read the temperature data collected and stored by each temperature sensor from the data register.

6. The graphics card information monitoring system according to claim 1, wherein: The graphics card also includes a configuration register; the configuration register is used to capture link status and error information and store them in the data register; the baseboard management controller is configured to send a link status and error information monitoring request instruction to the command register, and read the link status and error information captured and stored in the configuration register from the data register.

7. A server, characterized in that: It comprises the graphics card information monitoring system according to any one of claims 1-6.

8. A graphics card information monitoring method, characterized in that: Applied to a baseboard management controller, the method includes: Generate a request instruction including a first type of operation code and at least one parameter according to monitoring requirements, and send the request instruction to a command register of a graphics card; Obtaining a status bit returned by a command register of the graphics card, the status bit indicating an execution status of a processor of the graphics card parsing and executing a request instruction in the command register; Read data from or write data into a data register of a graphics card according to the request instruction; The first type of operation code is used to identify the type of the request instruction, and the parameter is used to identify the operation object corresponding to the request instruction.

9. The graphics card information monitoring method according to claim 8, characterized in that: The step of reading data from or writing data into a data register of a graphics card according to the request instruction includes: Based on the request instruction being a read operation, after obtaining a status bit returned by a command register of the graphics card, reading monitoring data corresponding to the request instruction from a data register of the graphics card; or, Based on the fact that the request instruction is a setting operation, before sending the request instruction to the command register of the graphics card, configuration data corresponding to the setting operation is written into the data register of the graphics card.

10. The method for monitoring graphics card information according to claim 8, wherein: Before sending the request instruction to the command register of the graphics card, it also includes: Send a query command to the graphics card's capability set register; Obtaining a support status of a graphics card capability set register corresponding to the request instruction returned based on the query instruction; In response to the support status corresponding to the request instruction being support monitoring, an operation of sending the request instruction to the command register of the graphics card is executed.

11. The method for monitoring graphics card information according to claim 8, wherein: Before generating a request instruction including a first type of operation code and at least one parameter according to monitoring requirements and sending the request instruction to the command register of the graphics card, the method further includes: Sending a driver status bit query instruction to a command register of a graphics card, wherein the driver status bit query instruction includes a second type of operation code; the second type of operation code is used to identify the driver status bit query instruction; Read the driver status bit of the graphics card's power management controller from the graphics card's data register; Generating a request instruction including a first-category opcode and at least one parameter according to monitoring requirements and sending the request instruction to the command register of the graphics card includes: generating a request instruction including a first-category opcode and at least one parameter according to a status value of the drive status bit and monitoring requirements, and sending the request instruction to the command register of the graphics card; wherein the drive status bit is a processor of the graphics card parsing and executing a drive status bit query instruction in the command register, reading the drive status bit from the power management controller and storing the data in the data register; and / or, Sending a communication status bit query instruction to a command register of a graphics card, wherein the communication status bit query instruction includes a third type of operation code; the third type of operation code is used to identify the communication status bit query instruction; Read the communication status bit of the graphics card's register controller from the graphics card's data register; In response to the status value of the communication status bit indicating that the communication is normal, an operation of sending a request instruction to the command register of the graphics card is executed; wherein, the communication status bit is parsed by the processor of the graphics card and executes the communication status bit query instruction in the command register, reads the communication status bit from the register controller and stores the data in the data register.

12. The method for monitoring graphics card information according to claim 11, wherein: The step of generating a request instruction including a first type of operation code and at least one parameter according to the state value of the drive state bit and the monitoring requirement, and sending the request instruction to the command register of the graphics card includes: Based on the status value of the driver status bit indicating that driver loading is incomplete, generating a first temperature monitoring request instruction including a first type of operation code and at least one parameter according to monitoring requirements, and sending the instruction to the command register of the graphics card; The step of reading data from a data register of the graphics card according to the request instruction includes: reading temperature data collected and stored by a temperature control circuit integrated in a processor of the graphics card from a data register of the graphics card according to the first temperature monitoring request instruction; or, Based on the status value of the driver status bit indicating that the driver loading is complete, generating a second temperature monitoring request instruction including a first type of operation code and at least one parameter according to the monitoring requirement, and sending the instruction to the command register of the graphics card; The reading of data from the data register of the graphics card according to the request instruction includes: reading temperature data collected and stored by temperature sensors at various components of the graphics card from the data register of the graphics card according to the second temperature monitoring request instruction.

13. The method for monitoring graphics card information according to claim 8, wherein: Sending a request instruction to the command register of the graphics card includes: sending a link status and error information monitoring request instruction to the command register of the graphics card; The reading of data from the data register of the graphics card includes: reading the link status and error information stored in the configuration register of the graphics card captured from the data register of the graphics card.

14. The method for monitoring graphics card information according to claim 8, wherein: Before sending the request instruction to the graphics card's command register, it also includes: Sending an asynchronous request to a command register of a graphics card, wherein the asynchronous request includes a fourth type of operation code; Writing data corresponding to the asynchronous request into the temporary memory of the graphics card; The acquiring the status bit returned by the command register of the graphics card comprises: sending a polling command to the command register of the graphics card to acquire the status bit returned by the command register of the graphics card; The fourth type of operation code is used to identify an asynchronous request.

15. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the graphics card information monitoring method according to any one of claims 8 to 14.

Images