JP2011022877A - Information processing apparatus and method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To shorten a period of time needed for a decode processing as a whole. <P>SOLUTION: When it is determined that a request command of decode (1) is transmitted, a device driver is notified of the decode (1) data are notified. The device driver creates a SGL (Scatter Gather List) for decode (1), creates a common buffer structural body for decode (1), and piles the created common buffer structural body for decode (1) on a queue 71. When the device driver receives a transfer completion notification of the data for decode (1) from decode hardware, it pushes the common buffer structural body for decode (1) from the queue 71. The present invention is applicable to an information processing system for supplying the decode hardware connected with a PCIe slot with the data for decode and performs decode processing. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to an information processing apparatus and method, and more particularly, to an information processing apparatus and method capable of shortening the entire decoding process.

  2. Description of the Related Art Conventionally, there is a decoding device that decodes an encoded stream obtained by encoding a moving image using an encoding method called MPEG (Moving Picture Experts Group). Of the MPEG series that have been standardized, MPEG2 is common, but recently, compression coding schemes such as MPEG4 with an increased compression rate and AVC (Advanced Video Coding) have also been standardized.

  When decoding such an encoded stream, for example, there is a method using a general CPU such as a microcomputer (see Patent Document 1).

  On the other hand, when a coded stream is decoded in a personal computer, there is a method of decoding using a hardware decoder (decode hardware) added to the personal computer, for example, by an expansion board.

  In this method, the personal computer supplies the encoded stream to the decoder when it becomes necessary to decode the encoded stream. When the decoder acquires the encoded stream from the personal computer, the decoder decodes the encoded stream and returns baseband data to the personal computer.

  As described above, in this method, it is necessary to transfer data and commands between the personal computer and the decoder.

  A first method of data transfer between the personal computer and the decoder will be described with reference to FIG. In the example of FIG. 1, an example in which two decoding processes are performed in succession is shown.

  The upper part of FIG. 1 shows processing of an application that runs on a personal computer. The middle part shows the data transfer process between the device driver on the personal computer and the decoder. The lower part shows the processing of the decoder. In the following description, the circled numbers in the drawings are replaced with numbers in parentheses.

  First, when a decode (1) request command is issued on the application, the device driver performs a management process of the decode (1) data placed in the main storage area on the personal computer, and Decode (1) data transfer is performed.

  When the data transfer for decoding (1) ends, the device driver notifies the decoder of the completion of data transfer for decoding (1), and the decoder starts the decoding (1) process.

  When the decoding (1) processing in the decoder is completed, decoding (1) result data transfer is performed to the application as data transfer processing. On the application, after the decoding (1) result data is acquired, the next decoding (2) request command is issued.

  After that, in the same way as the process of decoding (1), the device driver performs the management process of the data for decoding (2) placed in the main storage area on the personal computer, and the decoder performs the processing for decoding (2). Data transfer is performed.

  When the data transfer for decoding (2) is completed, the device driver notifies the decoder of the completion of data transfer for decoding (2), and the decoder starts the decoding (2) process.

  When the decoding (2) processing in the decoder is completed, decoding (2) result data transfer is performed to the application as data transfer processing.

  As described above, in the first method, after the decoding by the decoder is completed, the next decoding request is made. For this reason, in the first method, there is a time lag at the time T1 from the notification of the completion of the data transfer for decoding (1) in the data transfer processing to the time when the management processing of the data for decoding (2) is performed. It was happening.

  As a result, in the decoder, as shown in time T2 from the end of the decoding (1) process to the start of the decoding (2) process, the time interval for executing the decoding process that operates at a high speed is greatly increased. It was difficult to reduce the overall decoding processing time.

  Next, a second method of data transfer between the personal computer and the decoder will be described with reference to FIG. 2 also shows an example in which two decoding processes are performed continuously, as in the example of FIG.

  First, when a decode (1) request command is issued on the application, the device driver performs a management process of the decode (1) data placed in the main storage area on the personal computer, and Decode (1) data transfer is performed.

  At this time, on the application, the next decode (2) request command is queued by a mechanism (command queuing) that allows the decode request command provided on the application to be executed a plurality of times.

  When the data transfer for decoding (1) ends, the device driver notifies the decoder of the completion of data transfer for decoding (1), and the decoder starts the decoding (1) process.

  In addition, the decode (1) data transfer completion notification to the application is also made, and the next decode (2) request command queued on the application does not wait for acquisition of the result data for decode (2). publish.

  Correspondingly, the device driver performs a management process of data for decoding (2) placed in the main storage area on the personal computer.

  On the other hand, when the decoding (1) process at the decoder is completed, the decoding (1) result data is transferred to the personal computer as the data transfer process, and the decoding (1) result data is obtained on the application. Is done.

  After the decoding (1) result data transfer, when the decoding (2) data management process is completed, the decoding (2) data transfer is performed to the decoder.

  When the data transfer for decoding (2) is completed, the device driver notifies the decoder of the completion of data transfer for decoding (2), and the decoder starts the decoding (2) process. When the decoding (2) processing in the decoder is completed, decoding (2) result data transfer is performed to the application as data transfer processing.

  Thus, in the second method, decode command queuing by an application is used. As a result, during the decode (1) result data transfer, the decode (2) data completion processing is performed by the next decode (2) request command, and then the decode (2) data transfer is started immediately. It becomes possible. However, it is difficult to transfer the next data for decoding (2) during the previous decoding (1) process.

  As a result, also in the decoder of the second method, the time interval for executing the decoding process is as shown by time T3 from the end of the decoding (1) process to the start of the decoding (2) process. It opened greatly and it was difficult to shorten the overall decoding process time.

  Further, a third method of data transfer between the personal computer and the decoder will be described. A direct memory access controller (DMAC) mounted on the decoder has individual control registers such as Rx and Tx for one data transfer direction (referred to as DMA channel or DMA adapter).

  Each control register on the DMA cannot transfer data in one direction during data transfer in one direction, but can transfer data in the reverse direction. In the third method, one SGL (Scatter Gather List) is created for each data transfer request in the control register, data is copied to the common buffer, and then data transfer is performed.

  That is, in the third method, after the device driver receives a data request from an application, data management processing (SGL creation and copying to a common buffer) necessary for data transfer is performed. As a result, the time required for preprocessing for data transfer has become a bottleneck.

JP 2008-85615 A

  As described above, conventionally, even if the decoding speed of the decoder is increased, the data transfer time becomes a bottleneck, and it is difficult to reduce the entire decoding processing time. Therefore, it is difficult to obtain the effect of speeding up the entire decoding process.

  The present invention has been made in view of such a situation, and makes it possible to shorten the time of the entire decoding process.

  An information processing apparatus according to an aspect of the present invention creates a management list of necessary data in main memory in response to a request command issued for a predetermined process performed by another information processing apparatus, and A management information creating unit that loads a common buffer structure associated with a virtual memory space and a physical memory space in a queue, including a list, and the common buffer structure stacked in the queue by the management information creating unit When the data transfer is performed to the other information processing apparatus and the data transfer completion notification sent from the other information processing apparatus is received correspondingly, the data transfer is performed from the queue to the data transfer. The corresponding common buffer structure is released, and the next common buffer structure stacked in the queue is used for the next information processing apparatus. And performs data transfer.

  The management information creating means can create the management list for each decode request command issued for a decoding process performed by the other information processing apparatus, and load the common buffer structure in a queue.

  The data transfer means performs the next data transfer to the other information processing apparatus using one register of the other information processing apparatus, and the other information processing apparatus receives the data from the other information processing apparatus. Transfer of the result data that has been subjected to the predetermined processing can be performed by the other register of the other information processing apparatus.

  According to an information processing method of one aspect of the present invention, an information processing apparatus displays a management list of necessary data in main memory in response to a request command issued for a predetermined process performed by another information processing apparatus. A common buffer structure that is created and includes the management list and associated with a virtual memory space and a physical memory space is stacked in a queue, and the other information processing is performed using the common buffer structure stacked in the queue. The common buffer structure corresponding to the data transfer from the queue when the data transfer is performed to the device and the completion notification of the data transfer sent from the other information processing device correspondingly is received. Releasing the body and performing the next data transfer to the other information processing apparatus using the next common buffer structure stacked in the queue. No.

  In one aspect of the present invention, a management list of necessary data on the main memory is created in response to a request command issued for a predetermined process performed by another information processing apparatus, and includes the management list The common buffer structure in which the virtual memory space and the physical memory space are associated with each other is stacked in the queue. Then, using the common buffer structure stacked in the queue, the data is transferred to the other information processing apparatus, and the data sent from the other information processing apparatus correspondingly When the transfer completion notification is received, the common buffer structure corresponding to the data transfer is released from the queue, and the other information processing is performed using the next common buffer structure loaded in the queue. The next data transfer is performed to the device.

  According to the present invention, the entire decoding process can be shortened.

It is a figure explaining the example of the data transfer between the conventional device driver and a decoder. It is a figure explaining the other example of the data transfer between the conventional device driver and a decoder. It is a block diagram which shows the structural example of the information processing system to which this invention is applied. FIG. 3 is a block diagram illustrating a module configuration example in the personal computer of FIG. 2. It is a figure explaining a memory architecture. It is a flowchart explaining the DMA processing using SGL. It is a flowchart explaining the queuing process of SGL. It is a figure explaining the queuing process of SGL. It is a flowchart explaining the decoding process of the information processing system of FIG. It is a flowchart explaining the decoding process of the information processing system of FIG. It is a figure explaining the effect by the information processing system of FIG. It is a block diagram which shows the structural example of the hardware of a computer.

[Hardware configuration example]
FIG. 3 is a block diagram showing a configuration example of an embodiment of an information processing system to which the present invention is applied.

  In the information processing system shown in FIG. 3, the personal computer 12 supplies decoding data (compressed video data) to decoding hardware 11 connected to a PCIe (PCI express) slot (not shown) for decoding processing. This is a system for acquiring decoding result data (uncompressed video data).

  The decoding data is compressed and encoded by a compression encoding method such as MPEG (Moving Picture Experts Group) 2, MPEG4, or AVC (Advanced Video Coding).

  The decoding hardware 11 includes a PCIe board or a cassette type PCIe hardware unit. The decoding hardware 11 is configured to include a decoding unit 21, a CPU (Central Processing Unit) 22, a DMA (Direct Memory Access) controller 23, and a memory 24.

  The decoding unit 21 includes a decoding IC (Integrated Circuit) or the like. The decoding unit 21 decodes the decoding data stored in the memory 24 under the control of the firmware 31 operating on the CPU 22 by a method corresponding to the above-described compression encoding method, and the decoding result data is stored in the memory 24. Remember me.

  On the CPU 22, firmware 31 that is dedicated software is operating. The firmware 31 receives a decoding request command from the personal computer 12 and controls the decoding unit 21.

  The DMA controller 23 controls data transfer between the personal computer 12 and the decoding hardware 11. The DMA controller 23 has an Rx register 41 that is a control register for transferring data from the personal computer 12 to the memory 24, and a Tx register 42 that is a control register for transferring data from the memory 24 to the personal computer 12. ing.

  Since the Rx register 41 and the Tx register 42 are mounted on the DMA controller 23 one by one, data transfer in the reverse direction is possible during data transfer in one direction, but data transfer in the same direction is not possible. Is possible. For example, since the Rx register 41 is in use during data transfer from the personal computer 12 to the memory 24, the reverse Tx register 42 can be used, but the next data transfer in the Rx register 41 is Can not.

  The memory 24 handles data between the personal computer 12 and the decoding hardware 11 under the control of the DMA controller 23. The memory 24 can handle compressed or uncompressed data with the decoding unit 21.

  The personal computer 12 issues a decode request command and transmits it to the firmware 31 in response to an operation of an input unit (not shown) by the user. The personal computer 12 transmits the decoding data to the memory 24 via the Rx register 41 and receives the decoding result data of the memory 24 via the Tx register 42.

  The personal computer 12 is a personal computer, but is not limited thereto.

[Personal computer module configuration example]
FIG. 4 shows a module configuration example in a personal computer.

  In the example of FIG. 4, all modules of a user mode layer (User Mode Layer), a kernel mode layer (Kernel Mode Layer), and a hardware layer (Hardware Layer) that operate on a CPU (not shown) of the personal computer 12. It is shown. Of these modules, the modules related to the present invention are indicated by solid lines, and the others are indicated by dotted lines. Therefore, in the example of FIG. 4, only the modules related to the present invention are denoted by reference numerals, and only the flow up to the creation of the decoding result will be described.

  The user mode layer includes an application layer (Application Layer) and an application interface layer (API Layer). The application interface layer is further configured by an application interface and a driver access interface.

  The kernel mode layer is composed of a Windows Executive Service. The Windows Executive Service consists of Windows System Services, which is an OS, and modules such as an I / O Manager (I / O Manager) 54 and a memory manager (Memory Manager) 57 that run on the OS. ing.

  The hardware layer is composed of the decoding hardware 11 shown in FIG.

  An editing application 51 in the application layer has a GUI (Graphical User Interface) function. The editing application 51 issues a decode request command to the application interface (ApplicationIF.dll) 52 in accordance with a user operation input via the GUI function. Although an editing application will be described as an example, of course, other applications may be used.

  The application interface 52 is a compressed video that requires decoding from an auxiliary storage device (HDD) (not shown) mounted on the personal computer 12 with respect to the file system driver 56 of the I / O manager 54. Get the data. The application interface 52 uses the memory manager 57 on the OS to copy the acquired compressed video data to a main storage device (system memory) (hereinafter also referred to as main memory) (not shown).

  The application interface 52 also issues to the driver access interface (DriverIF.dll) 53 the address of the data copied on the system memory and a decode request command. The driver access interface 53 issues an address of data copied to the system memory and a decode request command to a device driver 55 which is one of the modules constituting the I / O manager 54.

  The device driver 55 creates a management list (Scatter Gather List: SGL) of data copied on the main memory in the I / O manager 54 operating on the OS. After creating the SGL, the device driver 55 makes a data transfer processing request to the DMA controller 23 by DMA while looking at the interval during which DMA control is possible. The device driver 55 issues a decode request command to the firmware 31 by CMD I / F Access immediately after the compressed video data is transferred to the memory 24.

  The DMA controller 23 uses the SGL that stores the address (physical address) of the main memory on the personal computer 12 notified from the device driver 55 to transfer the compressed video data to the memory 24 of the decoding hardware 11.

  The firmware 31 requests the decoding unit 21 to perform decoding processing. The decoding unit 21 reads the compressed video data from the memory 24, performs a decoding process, and writes the resulting uncompressed video data to the memory 24.

[Description of memory architecture]
First, a memory architecture in a personal computer will be described with reference to FIG.

  In the example of FIG. 5, the user space of virtual memory addresses “0x00000000” to “0x7FFFFFFF” and the system space of virtual memory addresses “0x80000000” to “0xFFFFFFFF” in the virtual memory space are shown on the leftmost side. On the right side, details of the system space in the virtual memory space are shown. In the upper right part of the details of the system space, details of the common buffer structure included in the area starting from the virtual address “0x88C25EA8” in the system space are shown.

  Below the details of the common buffer structure, details of the SGL entity arranged at virtual addresses “0xA1B33200” to “0xA1B31FF” in the system space are shown. Furthermore, on the right side, a common buffer including a SGL and a data buffer on the physical memory space are shown, and on the right side, details of the common buffer MDL are shown.

  The address on the physical memory space can be accessed from the decoding hardware 11 connected to the personal computer 12. The physical memory space can acquire an address from the device driver 55 operating in the OS kernel. However, the device driver 55 cannot directly control the physical memory space, and the device driver 55 also uses the address in the virtual memory space to control the physical memory space, like the editing application 51. Do.

  Here, the acquisition of the physical memory space address from the device driver 55 is performed as follows. That is, the Memory Descriptor List (MDL) managed by the I / O manager 54 in the OS lists associations between physical memory space addresses and virtual memory space addresses. Therefore, the device driver 55 can understand which physical memory space address is mapped to the virtual memory space by looking at the contents of the MDL.

[Description of DMA processing using SGL]
Based on such an architecture, a general DMA process using SGL used as a data transfer method according to the present invention will be described with reference to the flowchart of FIG. Note that the memory architecture shown in FIG. 5 is also referred to as appropriate along the processing of FIG.

  In step S1 in FIG. 6, the editing application 51 arranges (allocates) a data buffer for storing data in the main memory in the user space of the virtual memory space. As a result, as shown by A1 in FIG. 5, an 8 Mbytes data buffer is arranged at virtual memory addresses “0x013A0000” to “0x01B9FFFF” in the user space of the virtual memory space.

  In step S2, the memory manager 57 in the OS distributes and arranges data buffers arranged in the user space of the virtual memory space in the physical memory space on the main memory in units of a minimum of 4 KBytes. Thereby, as shown by A2 in FIG. 5, data buffers are distributed and arranged as data buffers 1 to X in the physical memory space of the main memory.

  In step S3, the device driver 55 requests the I / O manager 54 to create an SGL that is a list storing the buffer pointers (physical memory space addresses) of the distributed data buffers and buffer sizes. Correspondingly, as shown in A3 of FIG. 5, the I / O manager 54 performs SGL including a data buffer 1 pointer, a data buffer 1 size,..., A data buffer X pointer, and a data buffer X size of 8 bytes each. Is created.

  In step S4, the I / O manager 54 writes the SGL entity on the virtual memory space (its system space) so that the SGL can be accessed from the device driver 55. As a result, as shown in A4 of FIG. 5, an SGL entity of 32 Kbytes at the maximum is arranged at virtual memory addresses “0xA1B33200” to “0xA1B3B1FF” in the system space of the virtual memory space.

  Here, although the physical memory space address accessible from the hardware is stored in this SGL, it is written in the virtual memory space in step S4, so that the SGL can be referred to from the decoding hardware 11. Can not. In order to be able to refer to the SGL, it is necessary to create a buffer that can be referred to by both the personal computer 12 and the decoding hardware 11 called a common buffer in the physical memory space.

  In step S5, the device driver 55 prepares a structure for creating a common buffer and places it in “0x88C25EA8” in the virtual memory space. The common buffer structure includes a DMA adapter pointer, a virtual address of the common buffer entity (0x89F72000), and a common buffer MDL address (0x88C2D020), as indicated by A5 in FIG.

  In step S6, the device driver 55 creates the common buffer so as to secure it as a continuous area on the main memory. As a result, as indicated by A6 in FIG. 6, SGL buffers 1 to 128 are created in a continuous area of physical addresses “0x09A00000” to “0x09A7FFFF” of the physical memory space on the main memory.

  In step S7, the device driver 55 creates an MDL for associating the virtual memory space and the physical memory space in the common buffer. As a result, as shown at A7 in FIG. 6, a common buffer MDL composed of a pointer indicating the SGL buffers 1 to 128 or a buffer 1 pointer to a buffer 128 pointer which is an address is created. The common buffer MDL is arranged at a common buffer MDL address “0x88C2D020” (in the system space) included in the common buffer structure.

  As described above, since the common buffer has continuous addressing and is arranged in the physical memory space, the decoding hardware 11 can easily refer to the data in the common buffer.

  In step S8, the device driver 55 copies the SGL arranged in the virtual memory space in step S4 to the common buffer entity. However, since the device driver 55 is only allowed to control the virtual memory space, the device driver 55 uses the virtual memory space address as the address at the time of copying. Note that when the common buffer is copied to the virtual memory space, similar data is also arranged at an address in the physical memory space.

  That is, the SGL entity (A4) is copied to the common buffer entity (512 Kbytes) of the virtual memory addresses “0x89F72000” to “0x8A771FFF” in the system space, as indicated by A8 in FIG. By referring to the common buffer structure (A5), the SGL entity (A4) is also arranged in the common buffer (A6) in the physical memory space corresponding to the virtual address of the common buffer entity.

  Therefore, in step S9, the device driver 55 notifies the DMA controller 23 of the decoding hardware 11 of the physical addresses “0x09A00000” to “0x09A7FFFF” of the common buffer in the physical memory space shown by A9 in FIG. As a result, the DMA controller 23 can refer to the contents of the application data buffer placed in the physical memory space in the SGL.

  In step S10, the DMA controller 23 performs data transfer to the memory 24 in the decoding hardware 11 using these physical addresses (A9).

  The above is a general DMA control process. On the other hand, the present invention is characterized in that the SGL is stored in the common buffer (step S8) during the control process at the timing when the decode request command is issued, as will be described below. . In the present invention, when a command is issued continuously, a plurality of common buffers are created, and a common buffer structure is queued to prepare for DMA in advance. It is characterized by.

[Description of SGL queuing]
Next, SGL queuing processing will be described with reference to the flowchart of FIG. This process is performed for each data (thread) by the device driver 55. Note that FIG. 8 is also referred to as appropriate along the processing of FIG. In the following description, the circled numbers in the drawings are replaced with numbers in parentheses.

  In the example of FIG. 8, the process of the editing application 51, the process of the device driver 55, and the process of the decryption hardware 11 are shown from the left side. The queue 71 shown in the process of the device driver 55 is, for example, an I / O Built in the manager 54.

  The device driver 55 is waiting as a thread 1 (hereinafter referred to as a device driver 55 (thread 1)) until a decoding request command is transmitted from the editing application 51 in step S21. If it is determined in step S21 that the decode application (1) request command has been transmitted from the editing application 51, the device driver 55 (thread 1) is notified of the decode (1) data as shown in FIG. The process proceeds to step S22.

  That is, when a decoding (1) request command is transmitted from the editing application 51, the address of data required for decoding is notified from the driver access interface 53 to the device driver 55 (thread 1). As a result, the device driver 55 can create an SGL.

  In step S22, the device driver 55 (thread 1) creates an SGL for decoding (1) as shown in FIG. 8, and in step S23, the device driver 55 (thread 1) decodes (1 Create a common buffer structure for). As described above with reference to FIG. 6, the SGL for decoding (1), that is, the common buffer structure for decoding (1) storing the data for decoding (1) is created.

  In step S24, the device driver 55 (thread 1) loads (queues) the created common buffer structure for decoding (1) in the queue 71.

  The same applies to the case of decoding (2). That is, it is determined from the editing application 51 that a decode request command has been transmitted in step S21, and the decode (2) data in FIG. 8 is notified. In response to this, the device driver 55 creates the SGL for decoding (2) in step S22 as thread 2 (hereinafter referred to as device driver 55 (thread 2)), as shown in FIG. . In step S23, the device driver 55 (thread 2) creates a common buffer structure for decoding (2). As a result, an SGL for decoding (2), that is, a common buffer structure for decoding (2) in which data for decoding (2) is stored is created.

  In step S24, the device driver 55 (thread 2) loads the created common buffer structure for decoding (2) in the queue 71. As a result, the common buffer structure for decoding (2) is stacked on the queue 71 on the common buffer structure for decoding (1).

  Since there is a possibility that the decoding hardware 11 refers to the physical memory space address by SGL in the common buffer, the device driver 55 (thread 1) completes the transfer of the data for decoding (1) in step S25. Waiting for notification. Meanwhile, the common buffer structure for decoding (1) is held in the queue 71.

  If it is determined in step S25 that the previous transfer completion notification of the data for decoding (1) has been received from the decoding hardware 11, the device driver 55 (thread 1) assumes that there is no SGL reference, and the process proceeds to step S25. Proceed to S26. In step S26, the device driver 55 (thread 1) pushes (ejects) the common buffer structure for decoding (1) from the queue 71 in FIG. 8, and sets the common buffer structure for decoding (1). Release (= release the common buffer itself).

  Next, in the case of decoding (3) as well, the editing application 51 determines in step S21 that a decoding request command has been transmitted, and notifies the decoding (3) data in FIG. Correspondingly, the device driver 55 creates the decoding (3) SGL as the thread 3 (hereinafter referred to as the device driver 55 (thread 3)) in step S22 as shown in FIG. In step S23, the device driver 55 (thread 3) creates a common buffer structure for decoding (3). As described above with reference to FIG. 6, the SGL for decoding (3), that is, the common buffer structure for decoding (2) storing the data for decoding (3) is thereby created.

  The device driver 55 (thread 3) loads the created common buffer structure for decoding (3) in the queue 71 in step S24. As a result, the common buffer structure for decoding (3) is stacked on the queue 71 on the common buffer structure for decoding (1).

  Thereafter, although not shown in the example of FIG. 8, a notification of completion of transfer of the next data for decoding (2) is received from the decoding hardware 11, and the data for decoding (2) and the data for decoding (3) are received. For data, the same processing as in the case of decoding (1) data is repeated.

  That is, the device driver 55 (thread 2 or 3) waits until receiving a transfer completion notification of the data for decoding (2) or (3) in step S25.

  If it is determined in step S25 that the transfer completion notification of the data for decoding (2) or (3) has been received from the decoding hardware 11, the device driver 55 (thread 2 or 3) assumes that there is no SGL reference. The process proceeds to step S26. In step S26, the common buffer structure for decoding (2) or (3) is pushed from the queue 71 in FIG. 8 to release the common buffer structure for decoding (1) (= the common buffer itself). Release).

[Description of decoding process]
Next, decoding processing by the information processing system in FIG. 3 will be described with reference to the flowcharts in FIGS. 9 and 10.

  In step S51, the editing application 51 makes a request for decoding (1) to the device driver 55, and makes a request for decoding (2) to the device driver 55 in step S52. That is, the editing application 51 issues decode request commands continuously.

  In response to the request for decoding (1), the device driver 55 performs the decoding (1) to the I / O manager 54 in step S71 as thread 1 (hereinafter referred to as device driver 55 (thread 1)). For SGL creation. In response to this, the I / O manager 54 creates the SGL for decoding (1) in step S91 and notifies the device driver 55 (thread 1) of the completion.

  On the other hand, in response to the request for decoding (2), the device driver 55 is referred to as thread 2 (hereinafter referred to as device driver 55 (thread 2)), and in step S111, the device driver 55 performs decoding ( 2) Make an SGL creation request. In response to this, the I / O manager 54 creates the SGL for decoding (2) in step S92, and notifies the device driver 55 (thread 2) of the completion.

  Upon receipt of the decode (1) SGL creation completion notification, the device driver 55 (thread 1) issues a decode (1) common buffer creation request to the I / O manager 54 in step S72. In response to this, the I / O manager 54 creates a common buffer for decoding (1) in step S93, and notifies the device driver 55 (thread 1) of the completion.

  Upon receipt of the decode (2) SGL creation completion notification, the device driver 55 (thread 2) issues a decode (2) common buffer creation request to the I / O manager 54 in step S112. In response to this, the I / O manager 54 creates a common buffer for decoding (2) in step S94, and notifies the device driver 55 (thread 2) of the completion.

  Upon receiving the completion notification of the creation of the common buffer for decoding (1), the device driver 55 (thread 1) makes a common buffer copy request for the SGL for decoding (1) to the I / O manager 54 in step S73. In response to this, in step S95, the I / O manager 54 performs the SGL copy for decoding (1) and notifies the device driver 55 (thread 1) of the completion.

  Upon receiving the completion notification of the creation of the common buffer for decoding (2), the device driver 55 (thread 2) makes a common buffer copy request for the SGL for decoding (2) to the I / O manager 54 in step S113. In response to this, the I / O manager 54 performs the SGL copy for decoding (2) in step S96, and notifies the device driver 55 (thread 2) of the completion.

  Upon receipt of the decode (1) SGL copy completion notification, the device driver 55 (thread 1) issues a decode (1) common buffer structure queuing request to the I / O manager 54 in step S74. In response to this, in step S97, the I / O manager 54 performs decoding (1) queuing in the queue 71 and notifies the device driver 55 (thread 1) of the completion.

  Upon receipt of the decode (2) SGL copy completion notification, the device driver (thread 2) issues a decode (2) common buffer structure queuing request to the I / O manager 54 in step S114. In response to this, in step S98, the I / O manager 54 performs decoding (2) queuing in the queue 71 and notifies the device driver 55 (thread 2) of the completion.

  Upon receiving the decoding (1) queuing completion notification, the device driver 55 (thread 1) immediately executes the decoding (1) data DMA to the DMA controller 23 in step S75. Specifically, the device driver 55 (thread 1) uses the common buffer structure stacked in the queue 71, refers to the common buffer structure, and executes the decoding (1) data DMA. The Rx register 41 is set.

  At almost the same time, the device driver 55 (thread 1) issues a decode (1) execution command to the firmware 31 in step S76.

  In response to execution of DMA from the device driver 55 (thread 1), the DMA controller 23 uses the Rx register 41 to transfer data for decoding (1) to the memory 24. When the data transfer for decoding (1) is completed, the DMA controller 23 notifies the device driver 55 (thread 1 and thread 2) of the completion of data transfer in the Rx register 41 in step S131.

  Although not shown in the example of FIG. 10, the device driver 55 (thread 1) pushes the common buffer structure for decoding (1) from the queue 71 in response to the completion of the data transfer in the Rx register 41 ( Step S26 in FIG.

  Further, when the completion of data transfer in the Rx register 41 is received, the next DMA execution in the Rx register 41 becomes possible. Therefore, in step S115, the device driver 55 (thread 2) decodes ( 2) Execute the data DMA. Specifically, the device driver 55 (thread 2) uses the common buffer structure stacked in the queue 71 and refers to the common buffer structure to execute the data DMA for decoding (2). The Rx register 41 is set.

  In response to execution of DMA from the device driver 55 (thread 2), the DMA controller 23 uses the Rx register 41 to transfer data for decoding (2) to the memory 24. When the data transfer for decoding (2) is completed, the DMA controller 23 notifies the device driver 55 (thread 1 and thread 2) of the completion of data transfer in the Rx register 41 in step S132.

  Although not shown in the example of FIG. 10, the device driver 55 (thread 2) pushes a common buffer structure for decoding (2) from the queue 71 in response to the completion of data transfer in the Rx register 41 ( Step S26 in FIG.

  On the other hand, when receiving the decode (1) execution command from the device driver 55 (thread 1), the firmware 31 causes the decode unit 21 to execute the decode (1) process in step S151. The decoding unit 21 reads and decodes the decoding (1) data in the memory 24 and writes the decoded data in the memory 24 again. When the decoding unit 21 completes the decoding (1) process, the firmware 31 notifies the device driver 55 (thread 1 and thread 2) and the editing application 51 of the completion of the decoding (1) process in step S152.

  Upon receiving the decode (1) process completion notification, the device driver 55 (thread 2) issues a decode (2) execution command to the firmware 31 in step S116. When receiving the decode (2) execution command from the device driver 55 (thread 2), the firmware 31 causes the decode unit 21 to execute the decode (2) process in step S153.

  On the other hand, when receiving the notification of completion of the decoding (1) process, the editing application 51 issues a decoding (1) result acquisition request to the device driver 55 (thread 1) in step S53.

  In response to this, the device driver 55 (thread 1) executes the decoding (1) result data acquisition DMA to the DMA controller 23 in step S77. Specifically, the device driver 55 (thread 1) sets the execution of the decode (1) result data acquisition DMA in the Tx register 42 of the DMA controller 23.

  In the case of the Tx register 42, the SGL creation performed between the device driver 55 (thread 1) and the I / O manager 54 is also performed before the DMA execution (indicated by the dotted line), as in the case of the Rx register 41. You may make it perform queuing of a common buffer structure. That is, it is possible to perform the same processes as steps S71 to S74 and the corresponding steps S91, S93, S95, and S97 before the process of step S77.

  The DMA controller 23 uses the Tx register 42 to execute DMA from the device driver 55 (thread 1), and uses the Tx register 42 to decode (1) result data from the memory 24. Perform the transfer. When the decoding (1) result data transfer is completed, the DMA controller 23 notifies the device driver 55 (thread 1 and thread 2) of the completion of the result data transfer in the Tx register 42 in step S133.

  When the result data transfer completion is received from the DMA controller 23, the device driver 55 (thread 1) supplies the result data for decoding (1) to the editing application 51 in step S78. Thereby, in the editing application 51, the result data for decoding (1) is acquired.

  In step S153, the decoding unit 21 reads and decodes the decoding (2) data in the memory 24, and writes the decoded data in the memory 24 again. When the decoding unit 21 completes the decoding (2) process, the firmware 31 notifies the device driver 55 (thread 1 and thread 2) and the editing application 51 of the completion of the decoding (2) process in step S154.

  Upon receiving this decoding (2) processing completion notification, the editing application 51 makes a decoding (2) result acquisition request to the device driver 55 (thread 2) in step S54.

  In response to this, the device driver 55 (thread 2) executes the decoding (2) result data acquisition DMA to the DMA controller 23 in step S117. Specifically, the device driver 55 (thread 2) sets the Tx register 42 of the DMA controller 23 to execute the decode (2) result data acquisition DMA.

  In the case of the Tx register 42 as well, the SGL creation and the I / O manager 54 performed between the device driver 55 (thread 2) and the I / O manager 54 are performed in the same manner as in the case of the Rx register 41 before DMA execution (indicated by a dotted line) You may make it perform queuing of a common buffer structure. That is, it is possible to perform the same processes as steps S111 to S114 and the corresponding steps S92, S94, S96, and S98 before the process of step S77.

  For the DMA execution from the device driver 55 (thread 2), the DMA controller 23 uses the Tx register 42 to perform the decoding (2) result data from the memory 24 to the device driver 55 (thread 2). Perform the transfer. When the decoding (2) result data transfer is completed, the DMA controller 23 notifies the device driver 55 (thread 1 and thread 2) of the completion of the result data transfer in the Tx register 42 in step S134.

  When the result data transfer completion is received from the DMA controller 23, the device driver 55 (thread 2) supplies the result data for decoding (2) to the editing application 51 in step S118. As a result, the editing application 51 acquires the result data for decoding (2).

  In the example of FIGS. 9 and 10, the example in which the data transfer preparation for decoding (2) is performed in parallel with the data transfer preparation for decoding (1) has been described, but the processing example is not limited to this. For example, the decode (2) data transfer preparation can be performed while the decode (1) data transfer preparation is completed and the decode (1) data is being transferred.

  As described above, since the SGL is created and the common buffer structure itself is queued for each decoding request from the editing application 51, the next decoding is performed while the decoding hardware 11 is performing the decoding process. Data can be transferred to the memory.

  Note that the use of a queuing mechanism in an application is generally performed mainly by queuing an execution command as described above with reference to FIG. On the other hand, the present invention is characterized by queuing memory management data (common buffer structure) for executing DMA.

  In other words, the DMA execution data prepared in advance is queued and the data is managed in the device driver, so that when the execution trigger is received from the decoding hardware, the next command is immediately executed. It becomes possible. Thereby, the effect as shown in FIG. 11 can be obtained.

[Explanation of information processing system effects]
Next, with reference to FIG. 11, the effect of data transfer between the personal computer 12 and the decryption hardware 11 will be described. In the example of FIG. 11, an example in which two decoding processes are performed in succession is shown.

  In the example of FIG. 11, the upper part shows processing of the editing application 51 operating on the personal computer 12. In the middle part, data transfer processing between the device driver 55 on the personal computer 12 and the decryption hardware 11 is shown. In the lower part, processing of the decoding hardware 11 is shown.

  First, when a decode (1) request command is issued on the editing application 51, a management process of data for decoding (1) placed in the main storage area on the personal computer 12 is performed as a data transfer process. Thereafter, data transfer for decoding (1) is performed in the Rx register 41 of the DMA controller 23. For this data transfer, the above-described packet DMA processing using SGL is used.

  On the editing application 51, by parallelizing the processing of the device driver 55 (thread processing in FIG. 9), the decode (2) request command is issued immediately after the decode (1) request command is issued. Thereby, as the data transfer processing, the management processing of the data for decoding (2) placed in the main storage area on the personal computer 12 can be performed in parallel with the data transfer for decoding (1).

  When the decoding (1) data transfer is completed, the device driver 55 is notified of the completion of the decoding (1) data transfer, and the decoding hardware 11 executes the decoding (1) process.

  In the data management process for decoding (2), queuing of SGL (that is, common buffer structure) is performed. Accordingly, when the device driver 55 receives the completion notification of the data transfer for decoding (1), the data transfer for decoding (2) in the Rx register 41 of the DMA controller 23 can be performed immediately.

  Further, the Rx register 41 and the Tx register 42 of the DMA controller 23 can be controlled independently. Thus, even if the decoding (1) process in the decoding hardware 11 is completed during the decoding (2) data transfer, the decoding (1) result data in the Tx register 42 of the DMA controller 23 can be transferred. it can.

  Further, during the decoding (1) result data transfer, the decoding (2) data transfer is completed, and the editing application 51 obtains the decoding (1) result and completes the decoding (2) data transfer. Is notified to the device driver 55.

  In the decoding hardware 11, the decoding (2) process is executed, the decoding (2) result data in the Tx register 42 of the DMA controller 23 is transferred, and the editing application 51 acquires the decoding (2) result. The

  In the information processing system of FIG. 3, since data transfer management is performed in the device driver 55 that can perform main memory management processing of the personal computer 12 for data transfer, such a data transfer pipeline is used. Can be achieved.

  That is, since the decoding (2) data transfer can be performed while the decoding (1) process is being performed, the efficiency of the decoding data transfer is increased. As a result, as shown at time T11, the decoding process execution interval in the decoding hardware 11 from the end of the decoding (1) process to the start of the decoding (2) process is conventional (FIGS. 1 and 2). ).

  As a result, it is possible to speed up the decoding processing time in the entire decoding hardware 11 as viewed from the editing application 51 side.

  Further, since processing is performed within the device driver 55, overhead such as notification of completion of data transfer to the editing application 51 does not occur, so that processing time can be shortened.

  As described above, in the present invention, a plurality of SGLs used in the packet DMA at the time of data transfer are created in response to the decode request command from the application. The created SGL is built into the common buffer by the device driver, and the common buffer structure is queued. When the completion of data transfer is notified, the created common buffer structure is immediately used for the next data transfer by the device driver.

  Thereby, the transfer efficiency of the data transferred to the memory on the decoding hardware is improved, and the decoding process is speeded up.

  In the device driver, data management processing for data transfer can be sequentially executed by pipeline processing. This reduces processing overhead.

  In the above description, an example in which two decoding processes are performed continuously has been described. However, the present invention is not limited to two, and the present invention can be applied to a plurality of decoding processes.

  In the above description, the example in which decoding is performed by the decoding hardware has been described. However, the processing to be performed by the hardware is not limited to decoding, and may be encoding or other processing. . For example, the present invention can also be applied to causing the connected hardware to perform heavy processing that requires computing power to be performed by a personal computer.

  Further, the interface between the personal computer and the hardware is not limited to PCIe, but may be another interface.

  The series of processes described above can be executed by hardware or can be executed by software. When a series of processing is executed by software, a program constituting the software is installed in the computer. Here, the computer includes a computer incorporated in dedicated hardware, a general-purpose personal computer capable of executing various functions by installing various programs, and the like.

  FIG. 12 is a block diagram showing an example of the hardware configuration of a computer that executes the above-described series of processing by a program. That is, the personal computer 12 of FIG. 3 is configured as shown in FIG.

  In a computer, a central processing unit (CPU) 301, a read only memory (ROM) 302, and a random access memory (RAM) 303 are connected to each other via a bus 304.

  An input / output interface 305 is further connected to the bus 304. An input unit 306, an output unit 307, a storage unit 308, a communication unit 309, and a drive 310 are connected to the input / output interface 305.

  The input unit 306 includes a keyboard, a mouse, a microphone, and the like. The output unit 307 includes a display, a speaker, and the like. The storage unit 308 includes a hard disk, a nonvolatile memory, and the like. The communication unit 309 includes a network interface and the like. The drive 310 drives a removable medium 311 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory.

  In the computer configured as described above, the CPU 301 loads the program stored in the storage unit 308 to the RAM 303 via the input / output interface 305 and the bus 304 and executes the program, for example. Is done.

  The program executed by the computer (CPU 301) can be provided by being recorded on a removable medium 311 as a package medium or the like, for example. The program can be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital broadcasting.

  In the computer, the program can be installed in the storage unit 308 via the input / output interface 305 by attaching the removable medium 311 to the drive 310. Further, the program can be received by the communication unit 309 via a wired or wireless transmission medium and installed in the storage unit 308. In addition, the program can be installed in advance in the ROM 302 or the storage unit 308.

  The program executed by the computer may be a program that is processed in time series in the order described in this specification, or in parallel or at a necessary timing such as when a call is made. It may be a program for processing.

  The embodiments of the present invention are not limited to the above-described embodiments, and various modifications can be made without departing from the scope of the present invention.

  11 Decoding hardware, 12 Personal computer, 22 CPU, 23 DMA controller, 24 Memory, 31 Firmware, 41 Rx register, 42 Tx register, 51 Editing application, 54 I / O manager, 55 Device driver, 56 File system driver, 57 memory manager, 71 queue

Claims (4)

A virtual memory space and a physical memory space including a management list of necessary data on the main memory, corresponding to a request command issued for a predetermined process performed by another information processing apparatus, and including the management list Management information creation means for placing a common buffer structure associated with each other in a queue;
Using the common buffer structure stacked in the queue by the management information creating means, data is transferred to the other information processing apparatus, and the corresponding information is sent from the other information processing apparatus. When the completion notification of the data transfer is received, the common buffer structure corresponding to the data transfer is released from the queue, and the next common buffer structure loaded in the queue is used, An information processing apparatus that performs the next data transfer to another information processing apparatus. The management information creation unit creates the management list for each decode request command issued for a decoding process performed by the other information processing apparatus, and loads the common buffer structure in a queue. Information processing device. The data transfer means performs the next data transfer to the other information processing apparatus using one register of the other information processing apparatus, and the other information processing apparatus receives the data from the other information processing apparatus. The information processing apparatus according to claim 1, wherein the result data subjected to the predetermined processing is transferred by the other register of the other information processing apparatus. Information processing device
A virtual memory space and a physical memory space including a management list of necessary data on the main memory, corresponding to a request command issued for a predetermined process performed by another information processing apparatus, and including the management list Queue the common buffer structure associated with
Using the common buffer structure loaded in the queue, data transfer is performed to the other information processing apparatus, and the data transfer sent from the other information processing apparatus corresponding thereto is completed. When the notification is received, the common buffer structure corresponding to the data transfer is released from the queue, and the next information processing apparatus uses the next common buffer structure stacked in the queue. An information processing method including a step of performing next data transfer.

Images