Patent Publication Number: US-9892481-B2

Title: CPU/GPU synchronization mechanism

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application is a continuation application claiming priority to U.S. patent application Ser. No. 13/193,779 filed Jul. 29, 2011 hereby expressly incorporated by reference herein. 
    
    
     BACKGROUND 
     This relates generally to computers that have general purpose processors and graphics processing units. 
     The memory used by user applications running on the general purpose or central processing unit and the memory used by a graphics processing unit are typically separated. A graphics processing unit driver copies data from the user space into driver memory for processing on a graphics processing unit. In a shared virtual memory model, data is not copied to the graphics processing unit, but, instead, it is shared between the graphics processing unit and the central processing unit. 
     Currently, in multithreaded applications, shared data is protected by locks called mutexes. Each thread that wants to access shared data must first lock a corresponding mutex to prevent other threads from accessing that mutex. This locking can be done through “spinning” on lock, but this technique is not efficient from power and performance points of view. 
     To optimize the central processing unit, the operating system provides system calls that allow a thread to sleep until a mutex is available and then notifies other threads when a mutex is unlocked. But this mechanism works only for threads that run on central processing unit cores. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a schematic depiction of one embodiment of the present invention; 
         FIG. 2  is extended thread and memory model in accordance with one embodiment of the present invention; 
         FIG. 3  is a flow chart for page fault handling in accordance with one embodiment of the present invention; and 
         FIG. 4  is a system depiction for one embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     For each thread group running on a graphics processor, an auxiliary shadow thread running on the central processing unit may be created, in one embodiment. When a thread running on the graphics processing unit wants to lock a mutex, if it wants to wait until the thread is freed by another task, the graphics thread sends a request to a shadow thread on the central processing unit. The shadow thread on the central processing unit issues the corresponding system called to the operating system. When the operating system gives a lock to the shadow thread, the shadow thread sends the notification to the thread on the graphics processing unit. 
     While the term graphics processing unit is used in the present application, it should be understood that the graphics processing unit may or may not be a separate integrated circuit. The present invention is applicable to situations where the graphics processing unit and the central processing unit are integrated into one integrated circuit. As used herein, a processor or processing unit may be a processor, controller, or coprocessor. 
     Referring to  FIG. 1 , a host/central processing unit  16  communicates with the graphics processing unit  18  in a processor-based system  10 . The host/central processing unit  16  may be part of any processor-based system, including a hardwired or mobile device. Examples of mobile devices include cellular telephones, laptop computers, tablet computers, and mobile Internet devices, to mention a few examples. The host central processing unit  16  includes user applications  20  which provide control information to a shadow thread  22 . The shadow thread  22  then communicates synchronization on sync and control information to the graphics processing unit driver  26 . A shadow thread also communicates with the host operating system  24 . 
     As shown in  FIG. 1 , the user level  12  includes a shadow thread  22  and the user applications  20 , while the kernel level  14  includes a host operating system  24 , and the graphics processing unit driver  26 . The graphics processing unit driver  26  is a driver for the graphics processing unit even though that driver is resident in the central processing unit  16 . 
     The graphics processing unit  18  includes, in user level  12 , a gthread  28  which sends control and synchronization messages to the operating system (pOS)  30  and receives messages from the operating system  30 . A gthread is user code that runs on the graphics processing unit, sharing virtual memory with the parent thread running on the central processing unit. The operating system  30  may be a relatively small operating system, running on the graphics processing unit, that is responsible for graphics processing unit exceptions. It is a small relative to the host operating system  24 , as one example. 
     User applications  20  are any user process that runs on the central processing unit  16 . The user applications  20  spawn threads on the graphics processing unit  18 . 
     An eXtended Threaded Library or XTL is an extension to create and manage user threads on the graphics processing unit. This library creates the shadow thread for each gthread and has library functions for synchronization. 
     User applications offload computations to the graphics processing unit using an extension of a traditional multithreaded model such as:
         xthread_create (thread, attr, gpu_worker,arg).       

     The gthread or worker thread created on the graphics processing unit shares virtual memory with the parent thread. It behaves in the same way as a regular thread in that all standard inter-process synchronization mechanisms, such as Mutex and semaphore, can be used. At the same time, a new shadow thread is created on the host central processing unit  16 . This shadow thread works as a proxy for exception handling units and synchronization between threads on the central processing unit and the graphics processing unit. 
     In some embodiments, the parent thread, the host shadow thread and the graphics processing unit worker threads may share virtual memory as shown in  FIG. 2 . Host/central processing unit  16  includes the parent thread  32  that generates the xthread_create( ) for the shadow thread  22 . The shadow thread  22  accesses the shadow stack which is a private address space in the process address space  36 . The parent thread  32  also accesses the memory descriptors  34  and the main stack, which is a private address space within the process address space  36 . The memory descriptors  34  may also communicate with the gthread worker  28 . The gthread worker  28  can access the gthread code within the process space  36  as well as the shared data section and the private gthread stack. The material in the upper blocks corresponds to the process model  38  and the lower blocks correspond to the memory model  40 . 
     Referring to  FIG. 3 , the synchronization algorithms may be implemented in hardware, software and/or firmware. In software embodiments, the algorithms may be implemented as computer executable instructions stored on a non-transitory computer readable medium such as an optical, semiconductor or magnetic memory. In  FIG. 3 , the flows for the host operating system  24 , the shadow thread  22 , driver  26  of the central processing unit  16 , and the operating system  30  and ring  3   57  in the graphics processing unit  18  are shown as parallel vertical flow paths with interactions between them indicated by generally horizontal arrows. 
     Continuing in  FIG. 3 , in one embodiment, at ring  3 , the gthread  28  tries to acquire a mutex from the user space by spinning for a short period of time, as indicated in block  60 , in column  57 . If the mutex is successfully acquired, as determined in diamond  61 , the program continues, as indicated in block  62 . If the mutex was not acquired because it was already locked by another thread, a call to the operating system  30  (“SYSCALL”) is made with an ACQUIRE op code. 
     In the operating system  30 , the SYSCALL is received. The operating system  30  sends a message to the driver called PassHostCommand. The PassHostCommand includes an op code of SYSCALL and a data address plus operation, as indicated in block  50 . Then the operating system  30  puts the calling thread to sleep, as indicated in block  54 . The calling thread then goes to idle, as indicated in block  56 . 
     The driver  26  in the central processing unit  16  transfers the message to the Xthread  22  using a transfer command. In the Xthread  22 , the transfer command is received. The xthread waited for this message from the driver, as indicated at block  44 . Then the Xthread performs the mutex lock, as indicated in block  46  and may include an SYSCALL to the host operating system  24 . The operating system  24  waits until the mutex is acquired, (i.e. there is a context switch), as indicated at  42 . After the mutex was acquired, the Xthread sends a resume execution command to the driver  26  and then waits for the next message from the driver, as indicated in block  48 . The driver  26  receives the resume execution command and sends a message PassGpuCommand to the operating system  30  in the graphics processing unit. The PassGpuCommand may include an op code of resume execution with no data, as indicated in block  52 . 
     The operating system  30  wakes up the thread, as indicated in block  58 , and sends a resume from SYSCAL to the gthread  28 . As a result, the gthread  28  continues working, as indicated in block  62 . The shadow thread may also be used to release a mutex. 
     The computer system  130 , shown in  FIG. 4 , may include a hard drive  134  and a removable medium  136 , coupled by a bus  104  to a chipset core logic  110 . A keyboard and mouse  120 , or other conventional components, may be coupled to the chipset core logic via bus  108 . The core logic may couple to the graphics processor  112 , via a bus  105 , and the central processor  100  in one embodiment. The graphics processor  112  may also be coupled by a bus  106  to a frame buffer  114 . The frame buffer  114  may be coupled by a bus  107  to a display screen  118 . In one embodiment, a graphics processor  112  may be a multi-threaded, multi-core parallel processor using single instruction multiple data (SIMD) architecture. 
     In the case of a software implementation, the pertinent code may be stored in any suitable semiconductor, magnetic, or optical memory, including the main memory  132  (as indicated at  139 ) or any available memory within the graphics processor. Thus, in one embodiment, the code to perform the sequences of  FIG. 3  may be stored in a non-transitory machine or computer readable medium, such as the memory  132 , and/or the graphics processor  112 , and/or the central processor  100  and may be executed by the processor  100  and/or the graphics processor  112  in one embodiment. 
       FIG. 3  is a flow chart. In some embodiments, the sequences depicted in this flow chart may be implemented in hardware, software, or firmware. In a software embodiment, a non-transitory computer readable medium, such as a semiconductor memory, a magnetic memory, or an optical memory may be used to store instructions and may be executed by a processor to implement the sequences shown in  FIG. 3 . 
     The graphics processing techniques described herein may be implemented in various hardware architectures. For example, graphics functionality may be integrated within a chipset. Alternatively, a discrete graphics processor may be used. As still another embodiment, the graphics functions may be implemented by a general purpose processor, including a multicore processor. 
     References throughout this specification to “one embodiment” or “an embodiment” mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one implementation encompassed within the present invention. Thus, appearances of the phrase “one embodiment” or “in an embodiment” are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be instituted in other suitable forms other than the particular embodiment illustrated and all such forms may be encompassed within the claims of the present application. 
     While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.