Abstract:
A method and system for directing image rendering, implemented in a computer system including a plurality of processors includes determining one or more processors in the system on which to execute one or more commands. A graphics processing unit (GPU) control application program interface (API) determines one or more processors in the system on which to execute one or more commands. A signal is transmitted to each of the one or more processors indicating which of the one or more commands are to be executed by that processor. The one or more processors execute their respective command. A request is transmitted to each of the one or more processors to transfer information to one another once processing is complete, and an image is rendered based upon the processed information by at least one processor and the received transferred information from at least another processor.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This Application claims the benefit of U.S. Provisional Application Ser. No. 62/121,968, filed on Feb. 27, 2015, the contents of which are incorporated by reference herein. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention is generally directed to application requests, and more particularly, to a method and apparatus for directing application requests for rendering. 
       BACKGROUND 
       [0003]    Computing systems may include more than one graphics processing unit (GPU). Conventional systems utilize additional GPUs through a graphics application program interface (API) as a single stream command.  FIG. 1  is a block diagram of an example conventional linked display adapter  100 . The adapter  100  includes an application entity  110 , which may provide one or more application draw commands , a graphics API  120 , a graphics driver  130 , a plurality of GPU command queues  140 , (designated  140   1 ,  140   2  . . .  140   N ), a master GPU  150 , a plurality of additional GPUs  155 , and a primary output display device  160 . The application draw commands may be in a sequence and specific to an API, while not being specific to a particular GPU. Additionally, the application draw commands may include ordered steps for a GPU to perform a repeatable set of calculations, (e.g., production of an output image from input geometry). 
         [0004]    In operation, the adapter  100  includes the application draw commands  110  submitted to the graphics API  120  as a single stream. The graphics API  120  relays the command to the graphics driver  130 , which submits the commands to the GPU command queues  140 . The queue, or queues,  140  that receives the command is selected by the graphics driver  130 . Each GPU  150  or  155  extracts its command from its respective command queue  140 , and displays the results of the command on the display  160 . Information may also be transferred between GPUs, (e.g., between GPU  150  and one or more GPUs  155  as shown). Frames may also be alternately rendered. For example, a first frame might be sent to the master GPU  150 , while a second frame is sent to the additional GPU  155  for rendering, with each subsequent frame alternating rendering between the two GPUs. 
         [0005]    However, there is no conventional method for directing by an application which GPU is to render a command, for example, in virtual reality (VR) rendering. It would therefore be beneficial to provide a method and apparatus for directing application requests for rendering. 
       SUMMARY OF EMBODIMENTS 
       [0006]    A method for directing image rendering, implemented in a computer system including a plurality of processors is disclosed. The method includes determining, by a graphics processing unit (GPU) control application program interface (API), one or more processors in the system on which to execute one or more commands. A signal is transmitted to each of the one or more processors indicating which of the one or more commands are to be executed by that processor. The one or more processors execute their respective command. A request is transmitted to each of the one or more processors to transfer information to one another once processing is complete, and an image is rendered based upon the processed information by at least one processor and the received transferred information from at least another processor. 
         [0007]    A system including a first processor in communication with an application entity, a second processor in communication with the application entity, and a display in communication with the first processor is disclosed. The first processor is configured to receive a first command from the application entity indicating that the first processor is to execute the first command. The second processor is configured to receive a second command from the application entity indicating that the second processor is to execute the second command and a third command from the application entity that the second processor is to transfer information to the first processor upon completion of execution of the second command. The first processor is further configured to render an image to the display based upon the processed command by the first processor and the received transferred information from the second processor. 
         [0008]    A non-transitory computer readable storage medium is disclosed. The non-transitory computer readable storage medium has instructions recorded thereon that, when executed by a computing device, cause the computing device to perform operations including: determining, by a graphics processing unit (GPU) control application program interface (API), one or more processors in the system on which to execute one or more commands, transmitting a signal to each of the one or more processors indicating which of the one or more commands are to be executed by that processor, executing, by the one or more processors, their respective command, transmitting a request to each of the one or more processors to transfer information to one another once processing is complete, and rendering an image based upon the processed information by at least one processor and the received transferred information from at least another processor 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0009]    A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein: 
           [0010]      FIG. 1  is a block diagram of an example conventional linked display adapter; 
           [0011]      FIG. 2  is a block diagram of an example device in which one or more disclosed methods may be implemented; 
           [0012]      FIG. 3  is a block diagram of an example display adapter; and 
           [0013]      FIGS. 4A-4E  depict an example method of performing virtual reality (VR) rendering. 
       
    
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
       [0014]    Although a more detailed description is provided below, briefly a method and apparatus are described for directing application requests for rendering. GPUs are selected for performing processing in accordance with application commands. 
         [0015]      FIG. 2  is a block diagram of an example device  200  in which one or more disclosed embodiments may be implemented. The device  200  may include a computer, for example, a desktop computer, a tablet computer, a gaming device, a handheld device, a set-top box, a television, or a mobile phone. The device  200  includes a processor  202 , a memory  204 , a storage  206 , one or more input devices  208 , and one or more output devices  210 . The device  200  may also optionally include an input driver  212  and an output driver  214 . It is understood that the device  200  may include additional components not shown in  FIG. 2 . 
         [0016]    The processor  202  may include a central processing unit (CPU), a graphics processing unit (GPU), a CPU and GPU located on the same die, or one or more processor cores, wherein each processor core may be a CPU or a GPU. The memory  204  may be located on the same die as the processor  202 , or may be located separately from the processor  202 . The memory  204  may include a volatile or non-volatile memory, for example, random access memory (RAM), dynamic RAM, or a cache. 
         [0017]    The storage  206  may include a fixed or removable storage, for example, a hard disk drive, a solid state drive, an optical disk, or a flash drive. The input devices  108  may include a keyboard, a keypad, a touch screen, a touch pad, a detector, a microphone, an accelerometer, a gyroscope, a biometric scanner, or a network connection (e.g., a wireless local area network card for transmission and/or reception of wireless IEEE 802 signals). The output devices  110  may include a display, a speaker, a printer, a haptic feedback device, one or more lights, an antenna, or a network connection (e.g., a wireless local area network card for transmission and/or reception of wireless IEEE 802 signals). 
         [0018]    The input driver  212  communicates with the processor  202  and the input devices  208 , and permits the processor  202  to receive input from the input devices  208 . The output driver  214  communicates with the processor  202  and the output devices  210 , and permits the processor  202  to send output to the output devices  210 . It is noted that the input driver  212  and the output driver  214  are optional components, and that the device  200  will operate in the same manner if the input driver  212  and the output driver  214  are not present. Although described embodiments include a main display, the invention may be practiced without a main display, and only include a source device of video. In this way, the control territory may be an office environment with a plurality of portable devices and no main display. 
         [0019]      FIG. 3  is a block diagram of an example display adapter  300 . The adapter  300  includes an application entity  310 , which may provide one or more application draw commands, a graphics API  320 , a graphics driver  330 , a plurality of GPU command queues  340 , (designated  340   1 ,  340   2  . . .  340   N ), a master GPU  350 , a plurality of additional GPUs  355 , a primary output display device  360 , a GPU Control API  370 , and a GPU Mask device  380 . The GPU Control API  370  includes a GPU Mask Control  371 , a GPU Transfer Control  372  and a GPU Queue Sync Control  373 . 
         [0020]    A method for directing application requests is described with reference to the signaling depicted in example display adapter  300  of  FIG. 3 . The application entity  310  submits commands to the graphics API  320  ( 391 ), which are passed along to the Graphics Driver  330 . The application also submits request for GPU control through the GPU Control API  370  ( 392 ). For example, to control command redirections to a particular GPU, the GPU Mask Control  371  may be utilized. To control information transfer between GPUs, the GPU Transfer Control  372  may be utilized. To control queue execution barriers to synchronize between GPU queues, the GPU Queue Sync Control  373  may be utilized. 
         [0021]    Once the control commands are received by the GPU Control API  370 , it issues commands to the Graphics Driver  330  ( 393 ). The Graphics Driver  330  issues GPU mask commands, (i.e., to control command redirections to GPUs), to the GPU Mask  380  to adjust the GPU mask value ( 394 ). That is, the GPU mask commands instruct the GPU Mask  380  which GPUs are to execute specific commands, which the GPU Mask  380  passes on to the GPU Command Queues  340 . Graphics commands are sent to the GPU Mask  380  by the Graphics Driver  330  ( 395 ) for redirection to specific GPU Command Queues  340 . In this manner, the GPU mask  380  may operate as a switching device that is controlled by the commands in the command stream or sequence that it receives to ensure operations occur in order. 
         [0022]    The Graphics Driver issues GPU Queue Sync commands to the GPU Command Queues  340  ( 396 ). Although signal  396  is shown as being transmitted to GPU 1  Command Queue  340   1 , all GPU Command Queues  340  are synchronized by the command. That is, synchronization events are introduced into the GPU Queues  340  via the GPU Queue Sync Control  373 . Effectively, to ensure proper functionality, the execution of one GPU queue relative to another may be stopped and started. Although GPUs may operate asynchronously, the operations performed on them may be ordered. For example, in a virtual reality (VR) example, a GPU connected to an output display waits for the transfer of data from a second GPU before being allowed to present the final combined image to the output display. Additionally, the Graphics Driver  330  may issue GPU transfer commands, (e.g., via the GPU Transfer Control  372 ), to specific GPU Queues requesting information be transferred between GPUs ( 396 ). In the example shown in  FIG. 3 , the transfer commands are being shown as directed to GPU 1  Command Queue  340   1 , but the commands could be issued to any GPU Command Queue  340 . These commands allow, for example, the master GPU  350  to share information with the one or more of the additional GPUs and its command queue, as shown in  FIG. 3 . The resultant data is then displayed on display  360 . 
         [0023]      FIGS. 4A-4E  depict an example method  400  of performing VR rendering.  FIGS. 4A-4E  depict an adapter substantially similar to the one described above in  FIG. 3 , and similar components are denoted with similar reference numerals to those depicted in  FIG. 3 . Additionally, the method shown in  FIG. 4  includes a VR Headset  410  for displaying the renderings. In  FIG. 4A , an application directs all set up commands for a “left eye” rendering utilizing the GPU Mask Control  371  to the master GPU  350 . In  FIG. 4B , an application directs all set up commands for a “right eye” rendering utilizing the GPU Mask Control  371  to an additional GPU  355 , (e.g., associated with GPU Command Queue  340   2 ).  FIG. 4C  shows normal draw commands being directed to both GPUs set up in  FIG. 4A and 4B  via the GPU Mask Control  371 . That is, the mask control is “set” to both GPUs  350  and  355  by the application. This setting may include setting a bit to “1” when a GPU is to be utilized and “0” when a GPU is not to be utilized. 
         [0024]    In  FIG. 4D , the application request a transfer of “right eye” information from GPU  355  to GPU  350 , and requests GPU  350  wait for the information. This is performed via the GPU Transfer Control  372  and GPU Queue Sync Control  373 . That is, the GPU Transfer Control  372  directs GPU  355  to transfer information to GPU  350 , while the GPU Queue Sync Control  373  directs GPU  350  to wait for completion of the transfer prior to executing commands submitted after the transfer request was issued. Alternatively, the GPU  350  could be directed to delay the wait until just prior to the result of the transferred data being utilized. In this case, the wait for the transfer may already be complete before the wait for completion would be executed, shortening or removing the wait time from the execution order. In  FIG. 4E , the application sets the GPU mask to the master GPU  350  via the GPU Mask Control  371  to direct the GPU  350  to render the composite image, (e.g., left and right eye renderings), to the VR Headset  410 . It should be understood that many variations are possible based on the disclosure herein. Although features and elements are described above in particular combinations, each feature or element may be used alone without the other features and elements or in various combinations with or without other features and elements. 
         [0025]    For example, the above method and devices may include multiple GPU Command Queues ( 340 ) direct to a single GPU (either  350  or  355 ). In this case, the command queues may be executed in an unspecified order relative to each other while maintaining a sequence within the same queue. Since the GPU Queue Sync Control ( 373 ) controls the starting and stopping of queues ( 340 ) relative to each other, any mandatory ordering or sequence of commands between two or more queues could be ensured even on a single GPU. 
         [0026]    The methods provided may be implemented in a general purpose computer, a processor, or a processor core. Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine. Such processors may be manufactured by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions and other intermediary data including netlists (such instructions capable of being stored on a computer readable media). The results of such processing may be maskworks that are then used in a semiconductor manufacturing process to manufacture a processor which implements aspects of the present invention. 
         [0027]    The methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of computer-readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).