A method for debugging multi-channel output in development of a display card

Abstract

The application provides a method for debugging multi-output in graphic card development, and solves the problem of difficult multi-output debugging of the graphic card in the early development stage, and comprises the following steps: S1, dividing the screen display of the graphic card into multiple paths, in a vertical arrangement mode, the RGBA values of the screen display are linearly arranged in the memory, and each screen display data is stored in the memory in the form of a whole block; in a horizontal arrangement mode, the RGBA values of the screen display are discontinuous in the memory, and the data of each screen display is stored in the memory in the form of a row of data strips; in a cross arrangement mode, every two adjacent screens are an integral whole, the two integrals are vertically arranged, and the two screens in each integral are horizontally arranged; S2, collecting all screen pixels in sequence, combining into a PPM file according to a given resolution, and outputting the screen display effect; and S3, performing subsequent debugging and verification of the graphic card.

Description

Technical Field

[0001] This invention relates to the field of graphics card debugging technology, and in particular to a method for debugging multiple outputs in graphics card development. Background Technology

[0002] The graphics card manufacturing process typically involves debugging the hardware design using an FPGA, followed by ASIC verification, tape-out to produce the display chip, and finally mounting the display chip onto a PCB board to become the final graphics card. This process is extremely complex and lengthy. Before the graphics card is manufactured, the main debugging and verification methods rely on FPGAs. Therefore, the performance of the FPGA and the external interfaces it provides are crucial factors influencing the development process.

[0003] In the graphics card development process, hardware design (a form of software) can be run using an FPGA. This involves converting the hardware design into a binary file, burning it into the FPGA, and then starting the FPGA to simulate hardware operation for debugging and verification. As the hardware simulating a graphics card, the FPGA requires external interfaces such as video memory, VGA, DP, and HDMI. However, these external interfaces are limited; typically only one or two are available for video output, making it impossible to simulate scenarios like multi-channel extended output of a graphics card. To address this, this application provides a method for debugging multi-channel extended output of a graphics card using limited video output interfaces. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to overcome the defects of the existing technology. The present invention proposes a method for debugging multiple outputs in the early stage of graphics card development, which can debug and verify multiple extended outputs.

[0005] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is: a method for debugging multiple outputs in graphics card development, comprising the following steps:

[0006] S1. Divide the graphics card output screen display into multiple channels, including multiple vertical arrangement mode, multiple horizontal arrangement mode, and multiple four-way arrangement mode.

[0007] In multi-channel vertical alignment mode, the RGBA values ​​displayed on the screen are linearly arranged in memory, and the data displayed on each screen is stored in memory as a whole block.

[0008] In multi-channel horizontal arrangement mode, the RGBA values ​​displayed on the screen are not contiguous in memory; the data displayed on each screen is stored in memory as row-like data bars.

[0009] In the multi-path grid arrangement mode, each pair of adjacent screens forms a whole, the two wholes are arranged vertically, and the two screens in each whole are arranged horizontally.

[0010] S2. Collect all screen pixels sequentially, combine them into a PPM file according to the given resolution, and display the output effect on the screen.

[0011] S3. Perform subsequent debugging and verification of the graphics card.

[0012] Furthermore, in the multi-path vertical arrangement mode, the screen pixel information calculation steps are as follows:

[0013] Starting point = (screen ordinal number - 1) × horizontal resolution × vertical resolution × RGBA,

[0014] Offset = Horizontal resolution × Vertical resolution × RGBA

[0015] Get screen pixel information = Get the length of offset bytes from the starting point.

[0016] Furthermore, in the multi-path horizontal arrangement mode, the screen pixel calculation steps are as follows:

[0017] Step size = (Total number of screens × Horizontal resolution × RGBA) × Vertical screen resolution

[0018] Starting point = (screen ordinal number - 1) × horizontal resolution × RGBA, Offset = horizontal resolution × RGBA

[0019] Get screen pixel information = starting from the starting point, get data of length offset bytes, and perform recursive operations of screen vertical resolution times. Each recursive operation requires recalculating the starting point and increasing the step size each time.

[0020] Furthermore, in the multi-path grid arrangement mode, the screen pixel calculation steps are as follows:

[0021] Step size = (Total number of screens × Horizontal resolution × RGBA) × Vertical screen resolution

[0022] Starting point = (screen ordinal number - 1) × horizontal resolution × RGBA,

[0023] Offset = Horizontal resolution × RGBA

[0024] Get screen pixel information = starting from the starting point, get data of length offset bytes, and perform recursive operations of screen vertical resolution times. Each recursive operation requires recalculating the starting point and increasing the step size each time.

[0025] Compared with the prior art, the beneficial effects of the present invention include: it can copy the frame buffer memory corresponding to any multi-channel extended display, and debug and verify the multi-channel extended output in the early stage of graphics card development, without having to wait until the chip is successfully fabricated and then made into a graphics card (at which stage there will be a real physical display output interface) for debugging, which greatly reduces development risk and saves valuable time for later overall debugging and testing. Attached Figure Description

[0026] The disclosure of this invention is illustrated with reference to the accompanying drawings. It should be understood that the drawings are for illustrative purposes only and are not intended to limit the scope of protection of this invention. In the drawings, the same reference numerals are used to refer to the same parts. Wherein:

[0027] Figure 1 This is a schematic diagram of a preferred embodiment of the present invention with four vertically arranged paths;

[0028] Figure 2 This is a schematic diagram showing the arrangement of screen pixels in memory in a preferred embodiment of the present invention with a four-way vertical arrangement mode;

[0029] Figure 3 This is a schematic diagram of a preferred embodiment of the present invention, showing a four-way horizontal arrangement.

[0030] Figure 4 This is a schematic diagram showing the arrangement of screen pixels in memory in a preferred embodiment of the present invention with a four-way horizontal arrangement mode;

[0031] Figure 5 This is a schematic diagram of a preferred embodiment of the present invention, showing a four-way grid arrangement.

[0032] Figure 6 This is a schematic diagram showing the arrangement of screen pixels in memory in a four-way grid pattern according to a preferred embodiment of the present invention. Detailed Implementation

[0033] It is readily understood that, based on the technical solution of this invention, those skilled in the art can propose various interchangeable structural methods and implementations without altering the essential spirit of the invention. Therefore, the following detailed embodiments and accompanying drawings are merely illustrative examples of the technical solution of this invention and should not be considered as the entirety of the invention or as limitations or restrictions on the technical solution of this invention.

[0034] According to one embodiment of the present invention, Figures 1-6 As shown.

[0035] In this embodiment, taking four-channel output and a screen resolution of 1920x1080 as an example, there are the following three output modes:

[0036] Four-way vertical arrangement mode

[0037] like Figure 1 As shown, the screen displays four screens vertically side-by-side. The frame buffers in memory are arranged linearly, and the pixel information of each screen is continuous in memory: the first 1920x1080x4 bytes correspond to the pixel information of the first screen (each pixel corresponds to 4 bytes, namely RGBA, with each of the four components occupying one byte. RGBA represents the color space of Red, Green, Blue, and Alpha). The next three 1920x1080x4 bytes correspond to the pixel information of the second, third, and fourth screens, respectively. When debugging multi-screen display during development, it is only necessary to read the corresponding frame buffer memory, combine it into a PPM file according to the given resolution (PPM files are generally used as intermediate files for image processing), and then see the actual display effect of the four screens, and then proceed to the next step of debugging and verification.

[0038] Figure 2 This describes the arrangement of screen pixels in memory in a four-way vertical arrangement mode: the first screen of pixels starts from offset 0 bytes and ends at 1920x1080x4 bytes; the second screen of pixels starts from offset 1920x1080x4 bytes and ends at 1920x1080x4x2 bytes; the third screen of pixels starts from offset 1920x1080x4x2 bytes and ends at 1920x1080x4x3 bytes; and the fourth screen of pixels starts from offset 1920x1080x4x3 bytes and ends at 1920x1080x4x4 bytes.

[0039] Four-way horizontal arrangement mode

[0040] like Figure 3 As shown, the screen displays four horizontally side-by-side. The pixel information for each screen is not contiguous in memory: the first row of pixels for the first screen is continuous, followed by the first row of pixels for the second screen, then the first row of pixels for the third screen, then the first row of pixels for the fourth screen, and so on. Therefore, to obtain the complete pixel information for the first screen, it is necessary to select and extract the pixel information belonging only to the first screen from memory, combine it into a PPM file according to the given resolution, and then observe the actual display effect of the four screens before proceeding with further debugging and verification.

[0041] Figure 4This describes the pixel arrangement in memory for the screen in a four-way horizontal array mode: The first row of pixels for the first screen starts at offset 0 bytes and ends at 1920x4 bytes; the second row starts at offset 1920x4x4 bytes and ends at offset 1920x4x4+1920x4 bytes, and so on, for a total of 1080 extractions. This completes the collection of all pixel information for the first screen. Similarly, for the second screen, the first row starts at offset 1920x4 bytes and ends at offset 1920x4+1920x4 bytes; the second row starts at offset 1920x(4+1)x4 bytes and ends at offset 1920x(4+1)x4+1920x4 bytes, and so on, for a total of 1080 extractions. This completes the collection of all pixel information for the second screen. The third... The first row of pixels on the third screen starts at an offset of 1920x4x2 bytes and ends at 1920x4x2+1920x4 bytes. The second row of pixels on the third screen starts at an offset of 1920x(4+2)x4 bytes and ends at 1920x(4+2)x4+1920x4 bytes. This process is repeated 1080 times to collect all pixel information for the third screen. The first row of pixels on the fourth screen starts at an offset of 1920x4x3 bytes and ends at 1920x4x3+1920x4 bytes. The second row of pixels on the fourth screen starts at an offset of 1920x(4+3)x4 bytes and ends at 1920x(4+3)x4+1920x4 bytes. This process is repeated 1080 times to collect all pixel information for the fourth screen.

[0042] Four-way grid arrangement pattern

[0043] like Figure 5 As shown, the screen displays four screens arranged in a grid pattern, combining horizontal and vertical arrangement. The first and second screens can be considered as one unit, the third and fourth screens as another, with the two units arranged vertically, and the two screens within each unit arranged horizontally. Therefore, the entire frame buffer can be divided into two parts: the frame buffer from offset 0 to 1920x2x1080x4 bytes belongs to the first and second screens, and the frame buffer from offset 1920x2x1080x4 bytes to 1920x4x1080x4 bytes belongs to the third and fourth screens.

[0044] Figure 6This describes the pixel arrangement in memory for the screen in a four-way grid pattern: The first row of pixels for the first screen starts at offset 0 bytes and ends at 1920x4 bytes; the second row starts at offset 1920x4x4 bytes and ends at offset 1920x4x4+1920x4 bytes, and so on, for a total of 1080 extractions. This completes the collection of all pixel information for the first screen. The second row of pixels for the second screen starts at offset 1920x4 bytes and ends at offset 1920x4+1920x4 bytes; the second row starts at offset 1920x(4+1)x4 bytes and ends at offset 1920x(4+1)x4+1920x4 bytes, and so on, for a total of 1080 extractions. This completes the collection of all pixel information for the second screen. The third row of pixels starts at offset 1920x1080x4x2 bytes. The process begins at byte 1920x1080x4x2+1920x4. The second row of pixels on the third screen starts at offset byte 1920x1080x4x2+1920x4x2 and ends at byte 1920x1080x4x2+1920x4x3. This process is repeated 1080 times, completing the collection of all pixel information for the third screen. Similarly, the first row of pixels on the fourth screen starts at offset byte 1920x1080x4x2+1920x4 and ends at byte 1920x1080x4x2+1920x4x2. The second row of pixels on the fourth screen starts at offset byte 1920x1080x4x2+1920x4x3 and ends at byte 1920x1080x4x2+1920x4x4. This process is repeated 1080 times, completing the collection of all pixel information for the fourth screen.

[0045] The technical scope of this invention is not limited to the content described above. Those skilled in the art can make various modifications and variations to the above embodiments without departing from the technical concept of this invention, and all such modifications and variations should fall within the protection scope of this invention.

Claims

1. A method for debugging multi-lane output in graphics card development, characterized in that, Includes the following steps: S1. Divide the graphics card output screen display into multiple channels, including multiple vertical arrangement mode and multiple horizontal arrangement mode; In multi-path vertical alignment mode, the number of bytes per pixel displayed on the screen is linearly arranged in memory, and the data displayed on each screen is stored in memory as a whole block. In multi-channel horizontal arrangement mode, the number of bytes per pixel displayed on the screen is not contiguous in memory; the data displayed on each screen is stored in memory as row-based data bars. S2. Collect all screen pixel information sequentially, combine them into a PPM file according to the given resolution, and display the screen output effect. S3. Perform subsequent debugging and verification of the graphics card; In the multi-path vertical arrangement mode, the screen pixel information calculation steps are as follows: Starting point = (screen ordinal number - 1) × horizontal resolution × vertical resolution × bytes per pixel; Offset = Horizontal resolution × Vertical resolution × Bytes per pixel; Get screen pixel information = Get a length of offset bytes from the starting point; In the multi-path horizontal arrangement mode, the screen pixel information calculation steps are as follows: Step size = Total number of screens × Horizontal resolution × Bytes per pixel; Starting point = (screen ordinal number - 1) × horizontal resolution × bytes per pixel; Offset = horizontal resolution × bytes per pixel. Get screen pixel information = starting from the starting point, get data of length offset bytes, and repeat the extraction operation of screen vertical resolution times. Each recursion requires recalculating the starting point and increasing the step size each time.

Images