WO2021132905A1 - 멀티-마스터를 지원하는 그래픽 처리 장치를 공유하는 시스템 온 칩 및 그래픽 처리 장치의 동작 방법 - Google Patents

멀티-마스터를 지원하는 그래픽 처리 장치를 공유하는 시스템 온 칩 및 그래픽 처리 장치의 동작 방법 Download PDF

Info

Publication number
WO2021132905A1
WO2021132905A1 PCT/KR2020/016794 KR2020016794W WO2021132905A1 WO 2021132905 A1 WO2021132905 A1 WO 2021132905A1 KR 2020016794 W KR2020016794 W KR 2020016794W WO 2021132905 A1 WO2021132905 A1 WO 2021132905A1
Authority
WO
WIPO (PCT)
Prior art keywords
operating system
processing unit
central processing
gpu
standalone
Prior art date
Application number
PCT/KR2020/016794
Other languages
English (en)
French (fr)
Inventor
최종상
김문수
Original Assignee
주식회사 텔레칩스
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 텔레칩스 filed Critical 주식회사 텔레칩스
Priority to DE112020006298.8T priority Critical patent/DE112020006298T5/de
Priority to US17/778,961 priority patent/US20230024607A1/en
Priority to JP2022537810A priority patent/JP7444993B2/ja
Publication of WO2021132905A1 publication Critical patent/WO2021132905A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7839—Architectures of general purpose stored program computers comprising a single central processing unit with memory
    • G06F15/7864—Architectures of general purpose stored program computers comprising a single central processing unit with memory on more than one IC chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G06F9/4408—Boot device selection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0721—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU]
    • G06F11/0724—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU] in a multiprocessor or a multi-core unit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1441—Resetting or repowering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3024—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7807—System on chip, i.e. computer system on a single chip; System in package, i.e. computer system on one or more chips in a single package
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45566—Nested virtual machines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support

Definitions

  • the present invention relates to a system on-chip (hereinafter, collectively referred to as 'SoC') sharing a graphics processing unit (hereinafter, collectively referred to as 'GPU') and a method of operating the same, -It is about SoC with GPU supporting multi-master.
  • 'SoC' system on-chip
  • 'GPU' graphics processing unit
  • 'CPU' Central Processing Unit
  • 'OS' Operating System
  • OSs require a single GPU or multiple GPUs to handle highly parallel computing tasks or image rendering.
  • GPU computing power required by each OS may change.
  • one CPU can send a job only to the dedicated GPU, and the other CPU can also send a job to the dedicated GPU only. Therefore, GPUs can only perform the job requested by one OS. For example, if there are three OSs in SoC and two GPUs, two OSs out of three OSs can use one CPU. and one OS is mounted on another CPU. At this time, two OSs mounted on one CPU cannot use one GPU at the same time. Therefore, only two OSs mounted on different CPUs can use each dedicated GPU. Therefore, even if multiple OSs are mounted on the SoC, an OS that cannot use the GPU may occur, which is a limitation of the SoC.
  • GPU supports multi-master rebooting using hypervisor.
  • hypervisors are used extensively to guarantee different GPU computing performance requirements and system operation.
  • the use of a hypervisor can burden the system in terms of development complexity and cost.
  • system-on-chip in which a plurality of OSs can share the GPU by using a system monitoring module that transmits the operating system (OS) execution state information of the CPU to the GPU.
  • OS operating system
  • SoC SoC
  • GPU GPU operating method
  • a GPU supporting multi-master is mounted, and by selectively connecting a system monitoring module mounted on a system-on-chip (SoC) with an OS or CPU, all OSs are system monitoring modules
  • SoC system-on-chip
  • all OSs are system monitoring modules
  • SoC system-on-a-chip
  • a system on chip SoC
  • CPUs central processing units
  • Operating System operating system
  • bus interface a bus interface
  • CPUs central processing units
  • a graphics processing unit GPU that is connected to each of the plurality of central processing units and communicates with each other through, and selectively connected to at least one central processing unit among the plurality of central processing units, and in the connected central processing unit at least one status monitoring device for transmitting execution status information of at least one executed operating system to the graphic processing device, wherein the graphic processing device is shared by the at least one operating system, and the at least one A sharing operation by the at least one operating system is controlled based on execution state information of the operating system.
  • the graphic processing apparatus may determine an operating system that is in an abnormal state based on the execution state information of the at least one operating system, and normally terminate the determined operation of the operating system.
  • the graphic processing device may stop the configuration until the operating system in the abnormal state completes rebooting.
  • the plurality of central processing units includes a first central processing unit executing a first stand alone operating system, and a second central processing unit executing a second stand alone operating system, wherein the at least one
  • the status monitoring device may include a first status monitoring device connected to the first central processing unit to transmit execution status information of the first standalone operating system to the graphic processing unit, and connected to the second central processing unit. , a second status monitoring device that transmits execution status information of the second standalone operating system to the graphic processing device.
  • the plurality of central processing units includes a first central processing unit executing a standalone operating system, a hypervisor program, and a second central processing unit executing at least one guest operating agent based on the hypervisor program, , wherein the at least one status monitoring device includes a first status monitoring device that is connected to the first central processing device and transmits execution status information of the standalone operating system to the graphic processing device, wherein the hypervisor program may transmit execution state information of the at least one guest operating system to the graphic processing device.
  • the plurality of central processing units are configured to execute a first central processing unit executing a first standalone operating system, a second standalone operating system, a hypervisor program, and at least one guest operating system based on the hypervisor program and a second central processing unit, wherein the at least one state monitoring unit is connected to the first central processing unit to transmit execution state information of the first standalone operating system to the graphic processing unit.
  • a status monitoring device, and a second status monitoring device connected to the second central processing unit to transmit execution status information of the second standalone operating system to the graphic processing unit, wherein the hypervisor program comprises: Execution state information of at least one guest operating system may be transmitted to the graphic processing unit.
  • a graphics processing unit mounted on a system on chip (SoC)
  • CPUs central processing units
  • the graphic processing device is a sharing operation for processing tasks requested by the operating system
  • the execution state information may be collected through a bus interface connected to a state monitoring device connected to at least one central processing unit.
  • One of the operating systems operates as a host operating system, and after the determining step, if the operating system operating in an abnormal state is the host operating system, the configuration of the graphic processing unit is completed until the reboot of the host operating system is completed. can be stopped
  • the execution state information may be collected from a hypervisor executed in an arbitrary central processing unit, and may include an execution state of at least one guest operating system executed by the hypervisor.
  • the execution state information is collected from the execution state information of at least one standalone operating system, which is collected through a bus interface connected to a state monitoring device connected to at least one central processing unit, and a hypervisor executed in any central processing unit. and the execution state of at least one guest operating system.
  • a single system-on-chip can cover various use cases with or without a hypervisor.
  • SoC system-on-chip
  • sharing the GPU it is theoretically possible to increase computing power by up to 100%.
  • SoC System-on-Chip
  • the GPU checks it and does not affect the other OS, so the system safety of the System-on-Chip (SoC) is improved. It can be guaranteed, and it can support rebooting per core.
  • the GPU can know the execution state information of all CPUs or OSs. Accordingly, a plurality of CPUs or OSs can share a GPU without a hypervisor, thereby reducing the cost of using the hypervisor and reducing the system cost.
  • SoC system-on-chip
  • FIG. 2 describes the operation of the system-on-chip (SoC) of FIG. 1 .
  • SoC system-on-chip
  • FIG. 4 illustrates the operation of the system-on-chip (SoC) of FIG. 3 .
  • SoC system-on-chip
  • FIG. 6 illustrates an operation of the system-on-chip (SoC) of FIG. 5 .
  • FIG. 7 is a flowchart illustrating an operation of a GPU according to an embodiment of the present invention.
  • ...unit ...group
  • ...module a unit that processes at least one function or operation, which may be implemented by hardware or software or a combination of hardware and software.
  • transmission or provision may include not only direct transmission or provision, but also transmission or provision indirectly through another device or using a detour path.
  • the central processing unit receives information from the outside, stores it, interprets and calculates the instructions of a computer program (Program Instructions), and outputs to the outside plays a role
  • the CPU controls the overall operation of the computer by exchanging information with the computer parts.
  • the CPU executes software, that is, an application program, an operating system (hereinafter, collectively referred to as an 'OS'), and device drivers.
  • the CPU runs the OS which is loaded into working memory.
  • the CPU executes various application programs to be run based on the OS.
  • the CPU may be provided as a multi-core processor including at least two independently drivable processors. Each of the processors can read and execute program instructions independently. Processors may be driven by different power supply voltages or may be driven by different operation clocks. For example, the processors may be homogeneous processors or may consist of heterogeneous processors.
  • the CPU may include at least one cluster, and each cluster may include a plurality of CPU cores.
  • CPU cores may process a plurality of instructions and data constituting software.
  • the CPU cores may fetch a plurality of instructions or data, process the fetched instructions or data, and store the fetched instructions or data in an internal register.
  • the software may include software embedded in the SoC or software developed in the user's user environment.
  • a graphics processing unit (hereinafter, collectively referred to as a 'GPU') performs various graphic operations according to a request from a CPU. That is, the GPU may convert the processing-requested data into data suitable for display.
  • the GPU has an arithmetic structure advantageous for parallel processing in which similar operations are repeatedly processed.
  • the GPU may generate a screen according to an instruction of the OS, and output the generated screen to the display device.
  • the GPU not only performs calculations for computer graphics, but can also be used for calculations in applications. By connecting programmable layers and high-precision operations to the graphics pipeline, you can perform stream processing on your data.
  • the GPU runs one kernel at a time in parallel on many records in the flow.
  • the GPU may include a plurality of cores.
  • the plurality of cores may be homogeneous cores or heterogeneous cores.
  • the role of scattering images on the screen is the most important.
  • the remaining cores in addition to the cores that perform image rendering can be used for general purposes such as floating point calculations and scientific calculations.
  • Each CPU may be a chipset including system memory
  • the GPU may be a special-purpose processor for processing graphic data such as video games.
  • the GPU is mainly delegated the code and data of the tasks to be processed through the CPU through the memory interface, and after copying it to the GPU local memory, the GPU processes it and copies the result back to the CPU's main memory.
  • 'SoC' System on chip, hereinafter, collectively referred to as 'SoC'
  • the CPU controls the GPU through a bus interface.
  • a hypervisor provides a virtual environment in which OSs can use hardware.
  • a hypervisor provides a virtual environment in which OSs use GPUs to create screens. In other words, OSs can share and use the GPU through the hypervisor.
  • a standalone OS means a standalone OS that does not boot using a library, an external module, or another OS. Therefore, an OS that boots by itself without a hypervisor is called a standalone OS.
  • the guest OS refers to a virtualization OS that is driven using virtualization software mounted on the host OS.
  • the role of controlling the entire system ie, GPU configuration and initialization, is performed by the host OS, and a standalone OS or a hypervisor may be the host OS.
  • GPU configuration and initialization may be controlled by only one host OS.
  • GPU configuration and initialization may be controlled by any OS.
  • one of the OSs becomes the main OS.
  • a standalone OS becomes the main OS.
  • the main OS performs the role of configuring and initializing the GPU only in the case of a full system restart.
  • the complexity of the GPU control problem may be increased.
  • GPU configuration and initialization consists of making a number of basic settings (Register setting), uploading necessary firmware (Firmware, FW), and operating the uploaded firmware so that the GPU can perform the tasks requested by the CPU, etc. It may include tasks and the like.
  • the basic setting includes a clock, a control bit setting, and the like.
  • SoC system-on-chip
  • GPU graphics processing device supporting multi-master
  • the configuration of the embodiments of the present invention schematically shows only the configuration related to the present invention, and for example, general configurations such as a power supply are omitted, but these are not not included in the embodiments of the present invention.
  • SoC system-on-chip
  • a system-on-chip (SoC) 100 includes one GPU 110 and two CPUs (CPU_1, CPU_2) 120 and 130 .
  • the GPU 110 and the CPUs 120 and 130 communicate with each other through an on-chip bus fabric 140 .
  • Each of the CPUs 120 and 130 may perform various functions, and one of them may serve to control the entire system of a system-on-chip (SoC).
  • SoC system-on-chip
  • the CPUs 120 and 130 run respective OSs.
  • CPU_1 120 runs standalone OS_1 121
  • CPU_2 130 runs standalone OS_2 131 .
  • GPU 110 supports multi-master. Accordingly, the GPU 110 may simultaneously receive and process a job from a plurality of OSs 121 and 131 .
  • the state monitoring device _1 150 is connected between the CPU_1 120 and the GPU 110
  • the state monitoring device _2 160 is connected between the CPU_2 130 and the GPU 110 .
  • SoC system-on-chip
  • one OS among OSs mounted on the system-on-chip (SoC) 100 operates as a host OS.
  • This is predetermined, and for example, the standalone OS_1 121 may operate as a host OS.
  • the standalone OS_1 121 configures and initializes the GPU 110
  • the standalone OS_1 121 and the standalone OS_2 131 can freely share and use the GPU 110 .
  • the shared GPU ( 110) In a stable system, even if abnormal states of the CPUs 120 and 130 and OSs 121 and 131 such as reset, restart, reboot, and crash occur, the shared GPU ( 110) must process all work requests requested by the OSs 121 and 131.
  • the hypervisor transmits the running state information of the OSs to the GPU 110 .
  • the hypervisor transmits execution state information of the OSs 121 and 131 to the GPU 110 . Therefore, even if an abnormal state occurs in one of the OSs 121 and 131 , the GPU 110 does not know this, and a problem occurs.
  • the status monitoring devices 150 and 160 connected to each CPU 120 , 130 check the execution status information of each OS 121 and 131 and transmit it to the GPU 110 .
  • the GPU 110 knows this even in the abnormal state of the CPUs 120 and 130 or the OSs 121 and 131 running on each CPU 120, 130, it is possible to properly process not only other normal requests but also abnormal requests. have.
  • the GPU configuration and initialization stops during the reboot of the standalone OS_1 121 . do.
  • the host OS 121 does not access the frozen GPU configuration.
  • the host OS 121 checks and checks the configuration state to ensure stable operation of other execution tasks requested by other cores. After rebooting, the host OS 121 may control the GPU configuration and submit jobs to the GPU 110 .
  • the GPU configuration may be controlled by the host OS 121 . After the reboot of the abnormal OS 131 that is not the host OS 121 , the job submission is restarted from the standalone OS_2 131 , not the host OS 121 .
  • FIG. 2 describes the operation of the system-on-chip (SoC) 100 of FIG. 1 .
  • SoC system-on-chip
  • the CPU_1 120 executes the standalone OS_1 121 (S103), and the CPU_2 130 performs the stand-alone operation (S103).
  • the standalone OS_1 121 of the CPU_1 120 interworks with the GPU 110 to configure and initialize the GPU (S107).
  • step S109 may be performed every set period between the standalone OS_1 121 of the CPU_1 120 and the status monitoring device _1 150 , or may be performed when a specific event (eg, an abnormal operation) occurs.
  • the state monitoring device_1 150 transmits the execution state information of the standalone OS_1 121 collected through step S109 to the GPU 110 (S111).
  • step S113 may be performed every set period between the standalone OS_2 131 of the CPU_2 130 and the status monitoring device_2 160 , or may be performed when a specific event (eg, an abnormal operation) occurs.
  • the state monitoring device_2 160 transmits the execution state information of the standalone OS_2 131 collected through the step S113 to the GPU 110 (S115).
  • FIG. 3 is a block diagram illustrating a configuration of a system-on-chip (SoC) according to another embodiment of the present invention, and shows a structure different from that of FIG. 1 . In this case, a description of the same configuration as in FIG. 1 will be omitted.
  • SoC system-on-chip
  • a system-on-chip (SoC) 200 includes one GPU 210 and two CPUs 220 and 230 .
  • the GPU 210 and the CPUs 220 and 230 communicate with each other through an on-chip bus fabric 240 .
  • the CPU_1 220 includes a plurality of guest OSs 221 and 222 and a hypervisor 223 executing them.
  • CPU_1 221 executes guest OS_1 221 and guest OS_2 222 .
  • CPU_2 230 includes a standalone OS 231 , and CPU_2 250 is connected to the state monitoring device 250 . That is, the state monitoring device 250 is connected only between the CPU_2 230 and the GPU 210 .
  • the execution state information of the guest OSes 221 and 222 is transmitted to the GPU 210 through the hypervisor 223 , and the execution state information of the standalone OS 231 is transmitted to the GPU through the state monitoring device 250 . forwarded to 210 .
  • one of the OSs 221 , 222 , 231 becomes a host OS.
  • the standalone OS 231 of the CPU_2 230 may be a host OS. Accordingly, only the standalone OS 231 can configure and initialize the GPU 210 . After the standalone OS 231 configures and initializes the GPU 210 , all OSs, ie, guest OS_1 221 , guest OS_2 222 , and the standalone OS 231 can freely share the GPU 210 . can
  • the shared GPU 210 is generated by a plurality of OSs 221 , 222 , 231 . It should be able to handle all work requests.
  • the hypervisor 223 transmits execution state information of the guest OSs 221 and 222 executed in the CPU_1 220 to the GPU 210 .
  • the state monitoring device 250 checks the execution state information of the standalone OS 231 running on the CPU_2 230 and transmits it to the GPU 210 .
  • the GPU 210 can recognize it, so that the GPU 210 can process not only the normal request but also the abnormal request.
  • the GPU configuration is stopped while rebooting.
  • the host OS 231 does not access the frozen GPU configuration.
  • the host OS 231 checks and checks the configuration state to ensure stable operation of other execution tasks requested by other cores.
  • the host OS 231 may control the GPU configuration and submit jobs to the GPU 210 .
  • the GPU configuration may be controlled by the host OS 231 .
  • reboot of the abnormal OS other than the host OS job submission from the OS other than the host OS is resumed.
  • FIG. 4 illustrates the operation of the system-on-chip (SoC) of FIG. 3 .
  • the CPU_2 230 executes the standalone OS 231 ( S201 ).
  • the standalone OS 231 operates as a host OS. Accordingly, the standalone OS 231 of the CPU_2 230 interworks with the GPU 210 to configure and initialize the GPU (S203).
  • step S205 may be performed every set period between the standalone OS 231 of the CPU_2 230 and the state monitoring device 250 or may be performed when a specific event (eg, abnormal operation) occurs.
  • a specific event eg, abnormal operation
  • the state monitoring device 250 transmits the execution state information of the standalone OS 231 collected in step S205 to the GPU 210 (S207).
  • the CPU_1 220 executes the guest OS_1 221 and the guest OS_2 222 ( S209 ).
  • the hypervisor 223 of the CPU_1 220 checks the execution state information of the guest OSs 221 and 222 executed in step S209 ( S211 ). In this case, step S211 may be performed every set period or may be performed when a specific event (eg, abnormal operation) occurs.
  • the hypervisor 223 of the CPU_1 220 transmits the execution state information of the guest OSs 221 and 222 collected through step S211 to the GPU 210 (S213).
  • FIG. 5 shows a system-on-chip (SoC) structure according to another embodiment of the present invention, and shows an embodiment in which the embodiments of FIGS. 1 and 3 are merged. In this case, the description of the same configuration as in FIGS. 1 and 3 will be omitted.
  • SoC system-on-chip
  • a system-on-chip (SoC) 300 includes one GPU 310 and two CPUs 320 and 330 .
  • the GPU 310 and the CPUs 320 and 330 communicate with each other through an on-chip bus fabric 340 .
  • the CPU_1 320 includes a guest OS_1 321 , a guest OS_2 322 , a hypervisor 323 , and a standalone OS_1 324 .
  • CPU_2 330 includes standalone OS_2 331 .
  • the CPU_1 320 executes a plurality of guest OSs 321 and 322 based on the hypervisor 323 .
  • CPU_1 320 independently runs standalone OS_1 324 .
  • the state monitoring device_1 350 is connected between the CPU_1 320 and the GPU 31 .
  • execution state information of the guest OSs 321 and 322 is transmitted to the GPU 310 through the hypervisor 323 .
  • the execution state information of the standalone OS_1 is transmitted to the GPU 310 through the state monitoring device_1 350 .
  • CPU_2 330 executes a standalone OS_2 331 , and a state monitoring device_2 360 is connected to CPU_2 330 .
  • the execution state information of the standalone OS_2 331 is transferred to the GPU 310 through the state monitoring device_2 360 .
  • the system-on-chip has two standalone OSs.
  • only one standalone OS 324 or 331 may be limited to configure and initialize the GPU.
  • the standalone OS 324 or 331 may be set to configure and initialize the GPU.
  • one of the standalone OSs 324 or 331 is set as the main OS, and the main OS may perform the role of configuring and initializing the GPU only in the case of a full system restart.
  • the GPU 310 can know this through status monitoring, so that it can process not only a normal request but also an abnormal request.
  • FIG. 6 illustrates an operation of the system-on-chip (SoC) of FIG. 5 .
  • SoC system-on-chip
  • the CPU_2 330 executes the standalone OS_2 331 ( S303 ).
  • the standalone OS_2 331 operates as a host OS. Accordingly, the standalone OS_2 331 of the CPU_2 330 performs configuration and initialization of the GPU in conjunction with the GPU 210 (S305).
  • the standalone OS_2 331 of the CPU_2 330 provides OS execution status information to the status monitoring device_2 360 at the request of the status monitoring device_2 360 ( S307 ).
  • the state monitoring device_2 360 transmits the execution state information of the standalone OS_2 331 collected in step S307 to the GPU 310 (S309).
  • the CPU_1 320 executes the standalone OS_1 324 , the guest OS_1 321 , and the guest OS_2 322 ( S311 ).
  • the state monitoring device_1 350 checks the execution state of the standalone OS_1 324 in conjunction with the CPU_1 320 ( S313 ). Then, the execution state information collected in step S313 is transferred to the GPU 310 (S315).
  • the hypervisor 323 of the CPU_1 320 checks execution state information of the guest OSs 321 and 322 executed in step S311 ( S317 ).
  • the hypervisor 323 of the CPU_1 320 transmits the execution state information of the guest OSs 321 and 322 collected through step S317 to the GPU 310 (S319).
  • steps S307, S313, and S317 may be performed every set period or may be performed when a specific event (eg, an abnormal operation) occurs.
  • FIGS. 1 to 6 are flowchart illustrating the operation of the GPU according to the embodiment of the present invention, and shows the operation of the GPU according to the embodiment as shown in FIGS. 1 to 6 .
  • the GPU (110 in FIG. 1 , 210 in FIG. 3 , 310 in FIG. 5 ) includes at least one state monitoring device ( 150 , 160 in FIG. 1 , 250 in FIG. 3 , 350 and 360 in FIG. 5 )
  • execution state information of the OSs is collected from the hypervisor (223 in FIG. 3 and 323 in FIG. 5 ), respectively ( S401 ).
  • the GPUs 110 , 210 , and 310 determine whether there is an OS in an abnormal state based on the collected execution state information ( S403 ).
  • the abnormal state may be one of reset, restart, reboot, and crash.
  • the GPUs 110 , 210 , and 310 determine whether the abnormal OS is the host OS ( S407 ). When it is determined that the OS in the abnormal state is the host OS, the GPUs 110 , 210 , and 310 stop configuring the GPU ( S409 ).
  • the GPUs 110 , 210 , and 310 determine whether the reboot of the host OS is complete ( S411 ), and upon completion, restart the GPU configuration and initialization ( S413 ).
  • step S407 if it is determined in step S407 that the OS in the abnormal state is not the host OS, the GPUs 110 , 210 , and 310 determine whether the rebooting of the OS in the abnormal state is completed ( S415 ).
  • the GPUs 110 , 210 , and 310 receive a job from the rebooted OS again when the OS in an abnormal state is rebooted ( S417 ).
  • the GPUs 110 , 210 , and 310 perform tasks requested by various OSs. If any OS becomes a problem and it is no longer necessary to perform the corresponding tasks, if the GPUs 110 , 210 , and 310 cannot know the abnormal state of the OS, the task of the OS cannot be normally terminated. Therefore, GPU resources may be wasted or Halt (Hanging).
  • the GPU (110, 210, 310) collects the status information of the OS through the status monitoring device (150, 160, 250, 350, 360) or the hypervisor (223, 323), so , it is possible to control the operation of the OS in an abnormal state.
  • the GPUs 110 , 210 , and 310 perform tasks requested by application programs executed on a plurality of masters (OSs). However, when one OS is rebooted, tasks requested to be performed by the corresponding OS remain in the current execution state on the GPUs 110 , 210 , and 310 . However, since the GPUs 110 , 210 , and 310 can know this, by terminating normally without further performing the tasks requested by the OS, there is a problem in performing tasks requested by other OSes, or GPU resources are consumed. Avoid unnecessary use.
  • OSs masters
  • the embodiment of the present invention described above is not implemented only through the apparatus and method, and may be implemented through a program for realizing a function corresponding to the configuration of the embodiment of the present invention or a recording medium in which the program is recorded.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Computer Security & Cryptography (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Hardware Redundancy (AREA)
  • Microcomputers (AREA)

Abstract

멀티-마스터를 지원하는 그래픽 처리 장치를 공유하는 시스템 온 칩이 제공된다. 시스템 온-칩(System on chip, SoC)은 적어도 하나의 운영 체제(Operating System)를 실행하는 복수의 중앙 처리 장치(Central Processing Unit, CPU), 버스 인터페이스를 통해 상기 복수의 중앙 처리 장치와 각각 연결되어 상호 통신하는 그래픽 처리 장치(Graphics Processing Unit, GPU), 그리고 상기 복수의 중앙 처리 장치 중 적어도 하나의 중앙 처리 장치와 선택적으로 연결되고, 연결된 중앙 처리 장치에서 실행된 적어도 하나의 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는 적어도 하나의 상태 모니터링 장치를 포함하고, 상기 그래픽 처리 장치는, 상기 적어도 하나의 운영 체제에 의하여 공유되고, 상기 적어도 하나의 운영 체제의 실행 상태 정보에 기초하여 상기 적어도 하나의 운영 체제에 의한 공유 동작을 제어한다.

Description

멀티-마스터를 지원하는 그래픽 처리 장치를 공유하는 시스템 온 칩 및 그래픽 처리 장치의 동작 방법
본 발명은 그래픽 처리 장치(Graphics Processing Unit, 이하, 'GPU'로 통칭함)를 공유하는 시스템 온-칩(System on chip, 이하, 'SoC'로 통칭함) 및 그 동작 방법에 관한 것으로서, 멀티-마스터(Multi-master)를 지원하는 GPU가 탑재된 SoC에 관한 것이다.
최근, SoC 설계에 따르면, 다양한 중앙 처리 장치(Central Processing Unit, 이하, 'CPU'로 통칭함)들과 그 CPU들에서 실행되는 운영 체제(Operating System, 이하, 'OS'로 통칭함)들을 제공하고 있다.
일반적으로, 서로 다른 OS들은 단일 GPU 또는 복수의 GPU에게 높은 병렬 컴퓨팅 작업 또는 이미지 렌더링을 처리하도록 요구한다. SoC의 사용 사례에 따라, 각 OS에서 요구하는 GPU 컴퓨팅 성능은 변경될 수 있다.
복수개의 CPU와 복수개의 GPU가 SoC에 탑재되는 경우, 하나의 CPU는 그 전용 GPU에게만 작업(Job)을 보낼 수 있고 다른 CPU 역시 그 전용 GPU에게만 작업을 보낼 수 있다. 따라서, GPU들은 1개의 OS에서 요청하는 작업(Job)밖에 수행할 수가 없다.예를들어, SoC에 3개의 OS가 있고 2개의 GPU가 있는 경우, 3개의 OS 중 2개의 OS는 하나의 CPU에 탑재되고 하나의 OS는 다른 CPU에 탑재된다. 이때, 하나의 CPU에 탑재된 2개의 OS가 동시에 한 GPU를 사용할 수가 없다. 따라서, 서로 다른 CPU에 탑재된 2개의 OS만 각각의 전용 GPU를 사용할 수가 있다. 따라서, SoC에 다수개의 OS를 탑재하더라도 GPU를 사용할 수 없는 OS가 발생할 수 있으므로, 이는 SoC의 제약 사항이 된다.
이를 해결하기 위해 종래에는 하이퍼바이저(Hypervisor)를 사용하여 GPU의 멀티-마스터(Multi-master) 지원을 제공하는 기술이 사용되고 있다. GPU는 하이퍼바이저를 사용하여 멀티-마스터의 리부팅(Rebooting)을 지원하였다.
그러나, 하이퍼바이저는 멀티-마스터 지원 외에도 다양한 GPU 컴퓨팅 성능 요구 사항과, 시스템 동작을 보증하기 위해 광범위하게 사용된다. 하지만, 하이퍼바이저의 사용은 개발 복잡성과 비용 관점에서 시스템에 부담이 될 수 있다.
본 발명이 해결하고자 하는 한 과제는 CPU의 OS(Operating System) 실행 상태 정보를 GPU로 전달하는 시스템 모니터링 모듈을 이용하여 복수의 OS가 GPU를 공유할 수 있는 시스템-온-칩(system-on-chip, SoC) 및 GPU 동작 방법을 제공하는 것이다.
본 발명이 해결하고자 하는 다른 과제는 멀티-마스터를 지원하는 GPU가 탑재되고, 시스템-온-칩(SoC)에 탑재된 시스템 모니터링 모듈을 OS 또는 CPU와 선택적으로 연결시킴으로써, 모든 OS가 시스템 모니터링 모듈을 통해 GPU를 공유하도록 하거나, 모든 OS가 하이퍼바이저를 통해 GPU를 공유하도록 하거나, 일부 OS는 시스템 모니터링 모듈을 통해 GPU를 공유하고 일부 OS는 하이퍼바이저를 통해 GPU를 공유하도록 하여, 하이퍼바이저 유무에 관계없이 다양한 사용 사례를 커버할 수 있는 시스템-온-칩(SoC) 및 GPU 동작 방법을 제공하는 것이다.
본 발명의 한 실시예에 따르면, 시스템 온-칩(System on chip, SoC)으로서, 적어도 하나의 운영 체제(Operating System)를 실행하는 복수의 중앙 처리 장치(Central Processing Unit, CPU), 버스 인터페이스를 통해 상기 복수의 중앙 처리 장치와 각각 연결되어 상호 통신하는 그래픽 처리 장치(Graphics Processing Unit, GPU), 그리고 상기 복수의 중앙 처리 장치 중 적어도 하나의 중앙 처리 장치와 선택적으로 연결되고, 연결된 중앙 처리 장치에서 실행된 적어도 하나의 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는 적어도 하나의 상태 모니터링 장치를 포함하고, 상기 그래픽 처리 장치는, 상기 적어도 하나의 운영 체제에 의하여 공유되고, 상기 적어도 하나의 운영 체제의 실행 상태 정보에 기초하여 상기 적어도 하나의 운영 체제에 의한 공유 동작을 제어한다.
상기 그래픽 처리 장치는, 상기 적어도 하나의 운영 체제의 실행 상태 정보에 기초하여, 비정상 상태인 운영 체제를 판별하고, 판별한 운영 체제의 작업을 정상 종료 처리할 수 있다.
상기 그래픽 처리 장치는, 상기 비정상 상태인 운영 체제가 호스트 운영 체제로 판단되면, 상기 비정상 상태인 운영 체제가 재부팅을 완료할때까지 구성을 중지할 수 있다.
상기 복수의 중앙 처리 장치는, 제1 스탠드얼론(Stand alone) 운영 체제를 실행하는 제1 중앙 처리 장치, 그리고 제2 스탠드얼론 운영 체제를 실행하는 제2 중앙 처리 장치를 포함하고, 상기 적어도 하나의 상태 모니터링 장치는, 상기 제1 중앙 처리 장치에 연결되어, 상기 제1 스탠드얼론 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는 제1 상태 모니터링 장치, 그리고 상기 제2 중앙 처리 장치에 연결되어, 상기 제2 스탠드얼론 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는 제2 상태 모니터링 장치를 포함할 수 있다.
상기 복수의 중앙 처리 장치는, 스탠드얼론 운영 체제를 실행하는 제1 중앙 처리 장치, 그리고 하이퍼바이저 프로그램, 그리고 상기 하이퍼바이저 프로그램 기반으로 적어도 하나의 게스트 운영 제제를 실행하는 제2 중앙 처리 장치를 포함하고, 상기 적어도 하나의 상태 모니터링 장치는, 상기 제1 중앙 처리 장치에 연결되어, 상기 스탠드얼론 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는 제1 상태 모니터링 장치를 포함하며, 상기 하이퍼바이저 프로그램은, 상기 적어도 하나의 게스트 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달할 수 있다.
상기 복수의 중앙 처리 장치는, 제1 스탠드얼론 운영 체제를 실행하는 제1 중앙 처리 장치, 그리고 제2 스탠드얼론 운영 체제, 하이퍼바이저 프로그램, 그리고 상기 하이퍼바이저 프로그램 기반으로 적어도 하나의 게스트 운영 체제를 실행하는 제2 중앙 처리 장치를 포함하고, 상기 적어도 하나의 상태 모니터링 장치는, 상기 제1 중앙 처리 장치에 연결되어, 상기 제1 스탠드얼론 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는 제1 상태 모니터링 장치, 그리고 상기 제2 중앙 처리 장치에 연결되어, 상기 제2 스탠드얼론 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는 제2 상태 모니터링 장치를 포함하고, 상기 하이퍼바이저 프로그램은, 상기 적어도 하나의 게스트 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달할 수 있다.
본 발명의 다른 실시예에 따르면, 시스템 온-칩(System on chip, SoC)에 탑재된 그래픽 처리 장치(Graphics Processing Unit, GPU)의 동작 방법으로서, 적어도 두개의 중앙 처리 장치(Central Processing Unit, CPU)로부터 각 중앙 처리 장치에서 실행된 운영 체제(Operating System)들의 실행 상태 정보를 수집하는 단계, 상기 실행 상태 정보에 기초하여 비정상 상태로 동작하는 운영 체제가 있는지 판단하는 단계, 그리고 비정상 상태로 동작하는 운영 체제의 기 작업을 정상적으로 종료 처리하고, 상기 비정상 상태로 동작하는 운영 체제의 재부팅이 완료될때까지 대기하는 단계를 포함하고, 상기 그래픽 처리 장치는, 상기 운영 체제들이 요구한 작업들을 처리하는 공유 동작을 수행하고, 상기 실행 상태 정보는, 적어도 하나의 중앙 처리 장치에 연결된 상태 모니터링 장치와 연결된 버스 인터페이스를 통하여 수집될 수 있다.
상기 운영 체제들 중 하나는 호스트 운영 체제로 동작하고, 상기 판단하는 단계 이후, 상기 비정상 상태로 동작하는 운영 체제가 호스트 운영 체제인 경우, 상기 호스트 운영 체제의 재부팅이 완료될때까지 그래픽 처리 장치의 구성을 중지할 수 있다.
상기 실행 상태 정보는, 임의의 중앙 처리 장치에서 실행된 하이퍼바이저로부터 수집되며, 상기 하이퍼바이저가 실행한 적어도 하나의 게스트 운영 체제의 실행 상태를 포함할 수 있다.
상기 실행 상태 정보는, 적어도 하나의 중앙 처리 장치에 연결된 상태 모니터링 장치와 연결된 버스 인터페이스를 통하여 수집된 적어도 하나의 스탠드얼론 운영 체제의 실행 상태 정보와, 임의의 중앙 처리 장치에서 실행된 하이퍼바이저로부터 수집된 적어도 하나의 게스트 운영 체제의 실행 상태를 포함할 수 있다.
본 발명의 실시예에 따르면, 하나의 시스템-온-칩(SoC)으로 하이퍼바이저 유무에 관계없이 다양한 사용 사례를 커버할 수 있다. 또한, GPU를 공유함으로써 이론적으로 컴퓨팅 성능을 최대 100%까지 높일 수 있다.
또한, 시스템-온-칩(SoC)에 탑재된 OS 중 하나가 재부팅하거나 비정상적인 상황이 발생해도, GPU가 이를 확인하여 다른 OS에 영향을 주지 않으므로, 시스템-온-칩(SoC)의 시스템 안전성을 보장할 수 있고, 코어 별 재부팅을 지원할 수 있다.
또한, 시스템-온-칩(SoC)에 탑재된 시스템 모니터링 장치가 연결된 CPU 또는 OS의 실행 상태 정보를 GPU로 전달하므로, GPU는 모든 CPU 또는 OS의 실행 상태 정보를 알 수가 있다. 따라서, 하이퍼바이저가 없이도 복수의 CPU 또는 OS가 GPU를 공유할 수 있으므로, 하이퍼바이저 사용 비용을 줄이고 시스템 비용을 절감 할 수 있다.
도 1은 본 발명의 한 실시예에 따른 시스템-온-칩(SoC)의 구성을 나타낸 블록도이다.
도 2는 도 1의 시스템-온-칩(SoC)의 동작을 설명한다.
도 3은 본 발명의 다른 실시예에 따른 시스템-온-칩(SoC)의 구성을 나타낸 블록도이다.
도 4는 도 3의 시스템-온-칩(SoC)의 동작을 설명한다.
도 5는 본 발명의 또 다른 실시예에 따른 시스템-온-칩(SoC)의 구성을 나타낸 블록도이다.
도 6은 도 5의 시스템-온-칩(SoC)의 동작을 설명한다.
도 7은 본 발명의 실시예에 따른 GPU의 동작을 나타낸 순서도이다.
아래에서는 첨부한 도면을 참고로 하여 본 발명의 실시예에 대하여 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시예에 한정되지 않는다. 그리고 도면에서 본 발명을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.
명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함" 한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다.
또한, 명세서에 기재된 "…부", "…기", "…모듈" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어나 소프트웨어 또는 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다.
본 명세서에서 "전송 또는 제공" 은 직접적인 전송 또는 제공하는 것 뿐만 아니라 다른 장치를 통해 또는 우회 경로를 이용하여 간접적으로 전송 또는 제공도 포함할 수 있다.
본 명세서에서 단수로 기재된 표현은 "하나" 또는 "단일" 등의 명시적인 표현을 사용하지 않은 이상, 단수 또는 복수로 해석될 수 있다.
본 명세서에서 도면에 관계없이 동일한 도면번호는 동일한 구성요소를 지칭하며, "및/또는" 은 언급된 구성 요소들의 각각 및 하나 이상의 모든 조합을 포함한다.
제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 구성요소들은 용어들에 의해 한정되어서는 안 된다. 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다.
본 명세서에서, 중앙 처리 장치(Central Processing Unit, 이하, 'CPU'로 통칭함)는 외부에서 정보를 입력받고, 기억하고, 컴퓨터 프로그램의 명령어들(Program Instructions)을 해석하여 연산하고, 외부로 출력하는 역할을 한다. CPU는 컴퓨터 부품과 정보를 교환하면서 컴퓨터 전체의 동작을 제어한다. CPU는 소프트웨어, 즉, 응용 프로그램(Application Program), 운영 체제(Operating System, 이하, 'OS'라 통칭함), 장치 드라이버들을 실행한다. CPU는 워킹 메모리에 로드되는 OS를 실행한다. CPU는 OS 기반에서 구동될 다양한 응용 프로그램들을 실행한다.
CPU는 적어도 2개의 독립적으로 구동 가능한 프로세서들을 포함하는 멀티-코어 프로세서(Multi-Core Processor)로 제공될 수 있다. 프로세서들 각각은 프로그램 명령들을 독립적으로 읽고 실행할 수 있다. 프로세서들은 서로 다른 전원 전압에 의해서 구동되거나, 서로 다른 동작 클록에 의해서 구동될 수도 있다. 예를들면, 프로세서들은 동종의 프로세서들일 수도 있고, 이종의 프로세서들로 구성될 수 있다.
CPU는 적어도 하나의 클러스터를 포함할 수 있으며, 각 클러스터는 복수개의 CPU 코어들로 구성될 수 있다. CPU 코어들은 소프트웨어를 구성하는 복수의 명령어(instruction)들 및 데이터를 처리할 수 있다. 일예로 CPU 코어들은 복수의 명령어들 또는 데이터를 패치(fetch)하고, 패치된 명령어들 또는 데이터를 처리하며, 이를 내부 레지스터에 저장할 수 있다. 이때, 소프트웨어는 SoC에 내장된 소프트웨어 또는 사용자의 사용자 환경에서 개발되는 소프트웨어를 포함할 수 있다.
그래픽 처리 장치(Graphics Processing Unit, 이하, 'GPU'로 통칭함)는 CPU의 요청에 따라 다양한 그래픽 연산을 수행한다. 즉, GPU는 처리 요청된 데이터를 디스플레이에 적합한 데이터로 변환할 수 있다. GPU는 유사한 연산을 반복해서 처리하는 병렬 처리에 유리한 연산 구조를 가진다. GPU는 OS들의 지시에 따라 화면을 생성하고, 생성된 화면을 디스플레이 장치로 출력할 수 있다.
GPU는 컴퓨터 그래픽스를 위한 계산을 수행할 뿐만 아니라, 응용 프로그램들의 계산에 사용할 수 있다. 프로그램 가능한 층과 고정도 연산을 그래픽 파이프라인에 연결하여 데이터에 스트림 프로세싱을 수행할 수 있다. GPU는 병렬로 한번에 하나의 커널을 흐름 속의 많은 레코드에 실행시킨다.
GPU는 복수의 코어들을 포함할 수 있다. 복수의 코어들은 동종의 코어들일 수도 있고, 이종의 코어들일 수 있다. GPU의 경우는 화면에 이미지를 뿌려주는 역할이 가장 우선적이다. 그러나 하드웨어가 발전하여 예전과 비교하여 상대적으로 저렴하게 집적할 수 있는 코어 수가 늘어남에 따라 이미지를 뿌려주는 렌더링을 수행하는 코어 이외에 남는 코어들로 부동소수점 연산이나 과학계산 등 범용으로도 사용할 수 있다.
각 CPU는 시스템 메모리를 포함하는 칩셋일 수 있고, GPU는 비디오 게임 등과 같은 그래픽 데이터의 처리를 위한 특수 목적 프로세서일 수 있다.
일반적으로 GPU는 주로 CPU를 통해 처리하여야할 작업들의 코드와 데이터를 메모리 인터페이스를 통해 위임받고, 이를 GPU 로컬 메모리에 복사한 후, GPU는 이를 처리하여 CPU의 메인 메모리에 결과를 다시 복사하는 구조이다. 이를 위해 CPU 및 GPU를 포함하는 집적 시스템(System on chip, 이하, 'SoC'로 통칭함)에서 CPU는 버스 인터페이스를 통해 GPU를 제어한다.
또한, 하이퍼바이저(hypervisor)는 OS들이 하드웨어를 이용할 수 있는 가상 환경을 제공한다. 예를들어, 하이퍼바이저는 OS들이 GPU를 이용하여 화면을 생성하는 가상 환경을 제공한다. 다시 말해서, OS들은 하이퍼바이저를 통해 GPU를 공유 및 사용할 수 있다.
또한, 본 명세서에서, 스탠드얼론(Standalone) OS는 라이브러리, 외부 모듈 또는 다른 OS를 사용하여 부팅하지 않는 독립형 OS를 의미한다. 따라서, 하이퍼바이저 없이 단독으로 부팅하는 OS를 스탠드얼론 OS라 한다. 그리고 게스트 OS는 호스트 OS 위에 탑재된 가상화 소프트웨어를 이용하여 구동되는 가상화 OS를 의미한다.
본 명세서에서, 시스템 전체를 제어하는 역할, 즉, GPU 구성 및 초기화는 호스트 OS가 수행하며, 스탠드얼론 OS 또는 하이퍼바이저가 호스트 OS가 될 수 있다.
한 실시예에 따르면, GPU 구성 및 초기화는 하나의 호스트 OS에 의해서만 제어될 수 있다.
다른 실시예에 따르면, GPU 구성 및 초기화는 모든 OS에 의해서 제어될 수 있다. 이 경우, 전원이 켜지면, OS들 중 하나가 메인 OS가 된다. 예를들어, 스탠드얼론 OS가 메인 OS가 된다. 이때, 메인 OS는 전체 시스템 재시작 사례에서만 GPU 구성 및 초기화 역할을 수행한다. 그런데, 여러 호스트 OS가 GPU 구성 및 초기화를 할 경우, GPU 제어 문제의 복잡성이 가중될 수 있다.
따라서, GPU 구성 및 초기화의 주체를 하나의 호스트 OS로 제한함으로써, 시스템-온-칩(system-on-chip)(100)의 효율적인 운영을 도모할 수 있다.
GPU 구성 및 초기화는 다수의 기본 셋팅(Register setting)을 하는 작업, 필요한 펌웨어(Firmware, FW)를 업로드하는 작업, 업로드된 펌웨어를 동작시켜 GPU가 CPU 등에서 요구한 작업을 수행할 수 있는 상태로 만드는 작업 등을 포함할 수 있다. 여기서, 기본 셋팅은 클록(clock), 제어 비트 셋팅(control bit setting) 등을 포함한다.
본 발명의 실시예에서는, 하나의 시스템-온-칩(SoC)으로 하이퍼바이저 유무에 관계없이 멀티-마스터(Multi-master)를 지원하는 GPU를 다수의 OS 또는 다수의 CPU 간에 공유하는 방안에 대하여 설명한다.
도면을 참고하여 본 발명의 실시예에 따른 멀티-마스터를 지원하는 그래픽 처리 장치를 공유하는 시스템-온-칩(SoC) 및 GPU 동작 방법에 대하여 설명한다.
이때, 본 발명의 실시예들의 구성은 본 발명과 관련있는 구성만을 개략적으로 도시한 것으로서, 예를들어 전원 장치 등과 같은 일반적인 구성은 생략하였으나, 이들이 본 발명의 실시예에 포함되지 않는 것은 아니다.
도 1은 본 발명의 한 실시예에 따른 시스템-온-칩(SoC)의 구성을 나타낸 블록도이다.
도 1을 참조하면, 시스템-온-칩(SoC)(100)은 하나의 GPU(110) 및 두개의 CPU(CPU_1, CPU_2)(120, 130)를 포함한다. GPU(110)와 CPU들(120, 130)은 온-칩(On-chip) 버스(bus) 패브릭(fabric)(140)을 통하여 상호 통신한다.
각 CPU(120, 130)는 다양한 기능을 수행할 수 있으며, 이 중 하나는 시스템-온-칩(SoC)의 시스템 전체를 제어하는 역할을 할 수 있다.
CPU들(120, 130)은 각각의 OS를 실행한다. CPU_1(120)은 스탠드얼론 OS_1(121)을 실행하고, CPU_2(130)는 스탠드얼론 OS_2(131)를 실행한다.
GPU(110)는 멀티-마스터를 지원한다. 따라서, GPU(110)는 동시에 다수의 OS(121, 131)로부터 작업(Job)을 수신하여 처리할 수 있다.
이때, CPU_1(120)과 GPU(110) 사이에는 상태 모니터링 장치_1(150)가 연결되고, CPU_2(130)와 GPU(110) 사이에는 상태 모니터링 장치_2(160)가 연결된다.
시스템-온-칩(SoC)(100)의 전원이 켜지면, 시스템-온-칩(SoC)(100)에 탑재된 OS들 중에서 하나의 OS가 호스트 OS로 동작한다. 이는 사전에 정해진 것으로서, 예를들어, 스탠드얼론 OS_1(121)이 호스트 OS로 동작할 수 있다.
스탠드얼론 OS_1(121)이 GPU(110)의 구성 및 초기화한 이후, 스탠드얼론 OS_1(121) 및 스탠드얼론 OS_2(131)는 GPU(110)를 자유롭게 공유하여 사용할 수 있다.
안정된 시스템에서, 리셋(reset), 재시작(restart), 재부팅(reboot), 크래시(crash)와 같은 CPU들(120, 130)과 OS들(121, 131)의 비정상적인 상태가 발생할지라도 공유된 GPU(110)는 OS들(121, 131)이 요구한 모든 작업 요청을 처리해야만 한다.
OS들의 실행 상태 정보는 하이퍼바이저가 GPU(110)로 전달하는 것이 일반적이다. 그러나, 도 1의 구조와 같이, 하이퍼바이저가 없는 구조에서는 OS들(121, 131)의 실행 상태 정보를 GPU(110)로 전달할 수 있는 방법이 없다. 따라서, OS들(121, 131) 중의 하나에서 비정상적인 상태가 발생해도 이를 GPU(110)가 알지 못해서 문제가 생긴다.
그러나, 본 발명의 실시예에서는 각 CPU(120, 130)에 연결된 상태 모니터링 장치들(150, 160)이 각 OS(121, 131)의 실행 상태 정보를 체크해서 GPU(110)로 전달한다.따라서, CPU(120, 130) 또는 각 CPU(120, 130)에서 실행하는 OS들(121, 131)의 비정상적인 상태에서도 GPU(110)가 이를 알고 있으므로, 다른 정상적인 요청 뿐만 아니라 비정상적인 요청도 제대로 처리 할 수 있다.
만약, 호스트 OS로 동작하는 스탠드얼론 OS_1(121)과, 스탠드얼론 OS_1(121)가 탑재된 CPU_1(120)가 비정상적으로 동작하는 경우, 스탠드얼론 OS_1(121)의 재부팅동안 GPU 구성 및 초기화는 중지된다. 재부팅되는 동안 호스트 OS(121)는 정지된 GPU 구성에 접근하지 않는다. 재부팅되는 동안 호스트 OS(121)는 다른 코어들에 의해 요청된 다른 실행 작업의 안정적인 동작을 보장하기 위해 구성 상태를 확인 및 체크한다. 재부팅 후에, 호스트 OS(121)는 GPU 구성을 제어하고 GPU(110)에게 작업을 제출할 수 있다.
반면, 호스트 OS가 아닌 스탠드얼론 OS_2(131)과 스탠드얼론 OS_2(131)가 탑재된 CPU_2(130)가 비정상적으로 동작하는 경우, GPU 구성은 호스트 OS(121)에 의해 제어될 수 있다. 호스트 OS(121)가 아닌 비정상적인 OS(131)의 재부팅 후에, 호스트 OS(121)가 아닌 스탠드얼론 OS_2(131)로부터 작업 제출은 다시 시작된다.
도 2는 도 1의 시스템-온-칩(SoC)(100)의 동작을 설명한다.
도 2를 참조하면, 시스템-온-칩(SoC)(100)의 전원이 온(S101)되면, CPU_1(120)는 스탠드얼론 OS_1(121)를 실행(S103)하고, CPU_2(130)는 스탠드얼론 OS_2(131)를 실행한다(S105).
CPU_1(120)의 스탠드얼론 OS_1(121)는 GPU(110)와 연동하여 GPU 구성 및 초기화를 수행한다(S107).
CPU_1(120)의 스탠드얼론 OS_1(121)는 상태 모니터링 장치_1(150)의 요청에 의해 OS 실행 상태 정보를 상태 모니터링 장치_1(150)에게 제공한다(S109). 이때, S109 단계는 CPU_1(120)의 스탠드얼론 OS_1(121)와 상태 모니터링 장치_1(150) 간의 설정된 주기마다 이루어지거나, 또는 특정 이벤트(예, 비정상 동작) 발생시 수행될 수 있다.
상태 모니터링 장치_1(150)는 S109 단계를 통해 수집한 스탠드얼론 OS_1(121)의 실행 상태 정보를 GPU(110)로 전달한다(S111).
또한, CPU_2(130)의 스탠드얼론 OS_2(131)는 상태 모니터링 장치_2(160)의 요청에 의해 OS 실행 상태 정보를 상태 모니터링 장치_2(160)에게 제공한다(S113). 이때, S113 단계는 CPU_2(130)의 스탠드얼론 OS_2(131)와 상태 모니터링 장치_2(160) 간의 설정된 주기마다 이루어지거나, 또는 특정 이벤트(예, 비정상 동작) 발생시 수행될 수 있다.
상태 모니터링 장치_2(160)는 S113 단계를 통해 수집한 스탠드얼론 OS_2(131)의 실행 상태 정보를 GPU(110)로 전달한다(S115).
도 3은 본 발명의 다른 실시예에 따른 시스템-온-칩(SoC)의 구성을 나타낸 블록도로서, 도 1과 다른 구조를 나타낸다. 이때 도 1과 동일한 구성의 설명은 생략한다.
도 3을 참조하면, 시스템-온-칩(SoC)(200)은 하나의 GPU(210) 및 두개의 CPU(220, 230)를 포함한다. GPU(210)와 CPU들(220, 230)은 온-칩(On-chip) 버스(bus) 패브릭(fabric)(240)을 통하여 상호 통신한다.
이때, CPU_1(220)은 복수의 게스트 OS(221, 222)와 이들(221, 222)을 실행하는 하이퍼바이저(223)를 포함한다. CPU_1(221)은 게스트 OS_1(221) 및 게스트 OS_2(222)를 실행한다.
CPU_2(230)는 스탠드얼론 OS(231)를 포함하고, CPU_2(250)는 상태 모니터링 장치(250)와 연결된다. 즉, 상태 모니터링 장치(250)는 CPU_2(230)과 GPU(210) 사이에만 연결된다.
이 경우, 게스트 OS(221, 222)의 실행 상태 정보는 하이퍼바이저(223)를 통해 GPU(210)로 전달되고, 스탠드얼론 OS(231)의 실행 상태 정보는 상태 모니터링 장치(250)를 통해 GPU(210)로 전달된다.
전원이 켜지면, OS들(221, 222, 231) 중 하나가 호스트 OS가 된다. 이때, CPU_2(230)의 스탠드얼론 OS(231)가 호스트 OS일 수 있다. 따라서, 스탠드얼론 OS(231)만 GPU(210)를 구성하고 초기화할 수 있다. 스탠드얼론 OS(231)가 GPU(210)를 구성하고 초기화한 후에, 모든 OS, 즉, 게스트 OS_1(221), 게스트 OS_2(222), 스탠드얼론 OS(231)는 GPU(210)를 자유롭게 공유할 수 있다.
리셋, 재시작, 재부팅, 크래쉬와 같은 CPU들(220, 230) 및 OS들(221, 222, 231)의 비정상적인 상태에서도 공유된 GPU(210)는 복수의 OS들(221, 222, 231)에 의한 모든 작업 요청을 처리할 수 있어야 한다.
하이퍼바이저(223)가 있는 CPU_1(220)에서는 상태 모니터링 장치가 필요없다. 하이퍼바이저(223)가 CPU_1(220)에서 실행되는 게스트 OS들(221, 222)의 실행 상태 정보를 GPU(210)로 전달한다.
반면, 상태 모니터링 장치(250)가 CPU_2(230)에서 실행되는 스탠드얼론 OS(231)의 실행 상태 정보를 확인해서 GPU(210)에게 전달한다.
따라서, OS들(221, 222, 231) 중 하나가 비정상적으로 동작하더라도, GPU(210)가 이를 알 수 있으므로, GPU(210)는 일반 요청 뿐만 아니라 비정상 요청도 처리할 수 있다.
만약, 비정상적인 CPU와 그 CPU에서 실행되는 OS가 호스트 OS, 즉, 스탠드얼론 OS(231)인 경우, GPU 구성은 재부팅되는 동안 정지된다. 재부팅되는 동안 호스트 OS(231)는 정지된 GPU 구성에 접근하지 않는다. 재부팅되는 동안 호스트 OS(231)는 다른 코어들에 의해 요청된 다른 실행 작업의 안정적인 동작을 보장하기 위해 구성 상태를 확인 및 체크한다.
재부팅 후에, 호스트 OS(231)는 GPU 구성을 제어하고 GPU(210)에게 작업을 제출할 수 있다. 비정상적인 CPU 및 그 CPU에서 실행되는 OS가 HOST OS가 아닌 경우, GPU 구성은 호스트 OS(231)에 의해 제어될 수 있다. 호스트 OS가 아닌 비정상적인 OS의 재부팅 후에, 호스트 OS가 아닌 OS로부터 작업 제출은 다시 시작된다.
도 4는 도 3의 시스템-온-칩(SoC)의 동작을 설명한다.
도 4를 참조하면, 시스템-온-칩(SoC)(100)의 전원이 온(S201)되면, CPU_2(230)는 스탠드얼론 OS(231)를 실행(S201)한다. 이때, 스탠드얼론 OS(231)가 호스트 OS로 동작한다. 따라서, CPU_2(230)의 스탠드얼론 OS(231)는 GPU(210)와 연동하여 GPU 구성 및 초기화를 수행한다(S203).
CPU_2(230)의 스탠드얼론 OS(231)는 상태 모니터링 장치(250)의 요청에 의해 OS 실행 상태 정보를 상태 모니터링 장치(250)에게 제공한다(S205). 이때, S205 단계는 CPU_2(230)의 스탠드얼론 OS(231)와 상태 모니터링 장치(250) 간의 설정된 주기마다 이루어지거나, 또는 특정 이벤트(예, 비정상 동작) 발생시 수행될 수 있다.
상태 모니터링 장치(250)는 S205 단계를 통해 수집한 스탠드얼론 OS(231)의 실행 상태 정보를 GPU(210)로 전달한다(S207).
또한, CPU_1(220)는 게스트 OS_1(221) 및 게스트 OS_2(222)를 실행(S209)한다. CPU_1(220)의 하이퍼바이저(223)는 S209 단계에서 실행된 게스트 OS들(221, 222)의 실행 상태 정보를 체크(S211)한다. 이때, S211 단계는 설정된 주기마다 이루어지거나, 또는 특정 이벤트(예, 비정상 동작) 발생시 수행될 수 있다.
CPU_1(220)의 하이퍼바이저(223)는 S211 단계를 통해 수집한 게스트 OS들(221, 222)의 실행 상태 정보를 GPU(210)로 전달한다(S213).
도 5는 본 발명의 또 다른 실시예에 따른 시스템-온-칩(SoC) 구조를 나타내며, 도 1 및 도 3의 실시예가 병합된 실시예를 나타낸다. 이때, 도 1, 도 3과 동일한 구성의 설명은 생략한다.
도 5를 참조하면, 시스템-온-칩(SoC)(300)은 하나의 GPU(310) 및 두개의 CPU(320, 330)를 포함한다. GPU(310)와 CPU들(320, 330)은 온-칩(On-chip) 버스(bus) 패브릭(fabric)(340)을 통하여 상호 통신한다.
이때, CPU_1(320)은 게스트 OS_1(321), 게스트 OS_2(322), 하이퍼바이저(323) 및 스탠드얼론 OS_1(324)를 포함한다. CPU_2(330)은 스탠드얼론 OS_2(331)를 포함한다.
CPU_1(320)은 하이퍼바이저(323) 기반에서 복수의 게스트 OS(321, 322)를 실행한다. CPU_1(320)은 스탠드얼론 OS_1(324)를 독립적으로 실행한다. 이때, 상태 모니터링 장치_1(350)는 CPU_1(320)과 GPU(31) 사이에 연결된다. 이 경우, 게스트 OS들(321, 322)의 실행 상태 정보는 하이퍼바이저(323)를 통해 GPU(310)로 전달된다. 스탠드얼론 OS_1의 실행 상태 정보는 상태 모니터링 장치_1(350)를 통해 GPU(310)로 전달된다.
CPU_2(330)는 스탠드얼론 OS_2(331)를 실행하고, CPU_2(330)에는 상태 모니터링 장치_2(360)가 연결되어 있다. 스탠드얼론 OS_2(331)의 실행 상태 정보는 상태 모니터링 장치_2(360)를 통해 GPU(310)로 전달된다.
이때, 시스템-온-칩(SoC)은 스탠드얼론 OS가 두가지 존재한다. 하나의 실시예에 따르면, 한 스탠드얼론 OS(324 또는 331)만 GPU 구성 및 초기화를 하도록 제한할 수 있다. 다른 실시예에 따른 스탠드얼론 OS(324 또는 331)가 모두 GPU 구성 및 초기화를 하도록 설정할 수 있다. 이 경우, 스탠드얼론 OS(324 또는 331) 중 하나는 메인 OS로 설정되고, 메인 OS는 전체 시스템 재시작 사례에서만 GPU 구성 및 초기화 역할을 수행할 수 있다.
GPU 구성 및 초기화 이후, 시스템-온-칩(SoC) 내 모든 OS들은 GPU(310)를 자유롭게 공유하여 사용한다. 안정적인 시스템의 경우 재설정, 재시작, 재부팅, 크래시와 같은 비정상적인 CPU 및 OS 상태에서는 공유 GPU가 여러 OS의 모든 작업 요청을 처리 할 수 있다.
OS들(321, 322, 324, 331) 중 하나가 비정상적으로 동작하더라도, GPU(310)는 상태 모니터링을 통해 이를 알 수 있으므로, 일반 요청 뿐만 아니라 비정상 요청도 처리할 수 있다.
도 6은 도 5의 시스템-온-칩(SoC)의 동작을 설명한다.
도 6을 참조하면, 시스템-온-칩(SoC)(300)의 전원이 온(S301)되면, CPU_2(330)는 스탠드얼론 OS_2(331)를 실행(S303)한다.
이때, 스탠드얼론 OS_2(331)가 호스트 OS로 동작한다. 따라서, CPU_2(330)의 스탠드얼론 OS_2(331)는 GPU(210)와 연동하여 GPU 구성 및 초기화를 수행한다(S305).
CPU_2(330)의 스탠드얼론 OS_2(331)는 상태 모니터링 장치_2(360)의 요청에 의해 OS 실행 상태 정보를 상태 모니터링 장치_2(360)에게 제공한다(S307).
상태 모니터링 장치_2(360)는 S307 단계를 통해 수집한 스탠드얼론 OS_2(331)의 실행 상태 정보를 GPU(310)로 전달한다(S309).
또한, CPU_1(320)는 스탠드얼론 OS_1(324), 게스트 OS_1(321), 게스트 OS_2(322)를 실행(S311)한다.
상태 모니터링 장치_1(350)는 CPU_1(320)와 연동하여 스탠드얼론 OS_1(324)의 실행 상태를 체크한다(S313). 그리고 S313 단계에서 수집한 실행 상태 정보를 GPU(310)에게 전달한다(S315).
CPU_1(320)의 하이퍼바이저(323)는 S311 단계에서 실행된 게스트 OS들(321, 322)의 실행 상태 정보를 체크한다(S317). CPU_1(320)의 하이퍼바이저(323)는 S317 단계를 통해 수집한 게스트 OS들(321, 322)의 실행 상태 정보를 GPU(310)로 전달한다(S319).
이때, S307 단계, S313 단계, S317 단계는 설정된 주기마다 이루어지거나, 또는 특정 이벤트(예, 비정상 동작) 발생시 수행될 수 있다.
도 7은 본 발명의 실시예에 따른 GPU의 동작을 나타낸 순서도로서, 도 1 ~ 도 6과 같은 실시예에 따른 GPU의 동작을 나타낸다.
도 7을 참조하면, GPU(도 1의 110, 도 3의 210, 도 5의 310)가 적어도 하나의 상태 모니터링 장치(도 1의 150, 160, 도 3의 250, 도 5의 350, 360) 또는 하이퍼바이저(도 3의 223, 도 5의 323)로부터 OS들의 실행 상태 정보를 각각 수집한다(S401).
GPU(110, 210, 310)는 수집한 실행 상태 정보에 기초하여 비정상 상태인 OS가 있는지 판단한다(S403).
비정상 상태인 OS가 있으면, 비정상 상태인 OS의 기 작업을 정상적으로 종료 처리한다(S405). 비정상 상태는 리셋(reset), 재시작(restart), 재부팅(reboot), 크래시(crash) 중 하나일 수 있다.
GPU(110, 210, 310)는 비정상 상태인 OS가 호스트 OS인지 판단한다(S407). 비정상 상태인 OS가 호스트 OS로 판단되면, GPU(110, 210, 310)는 GPU 구성을 중지한다(S409).
GPU(110, 210, 310)는 호스트 OS의 재부팅이 완료되는지 판단(S411)한 후, 완료되면, GPU 구성 및 초기화를 재시작한다(S413).
한편, S407 단계에서 비정상 상태인 OS가 호스트 OS가 아니라고 판단되면, GPU(110, 210, 310)는 비정상 상태인 OS의 재부팅 완료 여부를 판단한다(S415).
GPU(110, 210, 310)는 비정상 상태인 OS가 재부팅 되면, 재부팅된 OS로부터 작업을 다시 수신한다(S417).
이와 같이, GPU(110, 210, 310)가 여러 OS에서 요청된 작업을 수행한다. 만약, 임의의 OS가 문제가 되어서 더 이상 해당 작업들을 수행하지 않아도 되는데 그 OS의 비정상 상태를 GPU(110, 210, 310)가 알 수 없으면, 그 OS의 작업을 정상 종료하지 못한다. 따라서, GPU 리소스가 낭비 또는 Halt(Hanging) 될 수 있다.
그러나, 본 발명의 실시예에 따르면, GPU(110, 210, 310)는 상태 모니터링 장치(150, 160, 250, 350, 360) 또는 하이퍼바이저(223, 323)를 통해 OS들의 상태 정보를 수집하므로, 비정상 상태인 OS의 동작을 제어할 수 있다.
일반적으로 정상적인 상태에서 GPU(110, 210, 310)는 여러 개의 마스터들(OS들)에서 실행되는 어플리케이션 프로그램들이 요청하는 작업들을 수행한다. 하지만, 하나의 OS가 리부트(reboot)되면 해당 OS에서 수행을 요청했던 작업들은 GPU(110, 210, 310)상에서 현재 수행 상태로 남아있다. 그러나, GPU(110, 210, 310)가 이를 알 수 있으므로, 해당 OS에서 요청해서 수행하던 작업들을 더 이상 수행하지 않고 정상적으로 종료시킴으로써, 다른 OS에서 요청된 작업들의 수행에 문제가 되거나, GPU 리소스를 불필요하게 사용하지 않도록 한다.
이상에서 설명한 본 발명의 실시예는 장치 및 방법을 통해서만 구현이 되는 것은 아니며, 본 발명의 실시예의 구성에 대응하는 기능을 실현하는 프로그램 또는 그 프로그램이 기록된 기록 매체를 통해 구현될 수도 있다.
이상에서 본 발명의 실시예에 대하여 상세하게 설명하였지만 본 발명의 권리범위는 이에 한정되는 것은 아니고 다음의 청구범위에서 정의하고 있는 본 발명의 기본 개념을 이용한 당업자의 여러 변형 및 개량 형태 또한 본 발명의 권리범위에 속하는 것이다.

Claims (10)

  1. 시스템 온-칩(System on chip, SoC)으로서,
    적어도 하나의 운영 체제(Operating System)를 실행하는 복수의 중앙 처리 장치(Central Processing Unit, CPU),
    버스 인터페이스를 통해 상기 복수의 중앙 처리 장치와 각각 연결되어 상호 통신하는 그래픽 처리 장치(Graphics Processing Unit, GPU), 그리고
    상기 복수의 중앙 처리 장치 중 적어도 하나의 중앙 처리 장치와 선택적으로 연결되고, 연결된 중앙 처리 장치에서 실행된 적어도 하나의 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는 적어도 하나의 상태 모니터링 장치를 포함하고,
    상기 그래픽 처리 장치는,
    상기 적어도 하나의 운영 체제에 의하여 공유되고, 상기 적어도 하나의 운영 체제의 실행 상태 정보에 기초하여 상기 적어도 하나의 운영 체제에 의한 공유 동작을 제어하는, 시스템 온-칩(SoC).
  2. 제1항에서,
    상기 그래픽 처리 장치는,
    상기 적어도 하나의 운영 체제의 실행 상태 정보에 기초하여, 비정상 상태인 운영 체제를 판별하고, 판별한 운영 체제의 작업을 정상 종료 처리하는, 시스템 온-칩(SoC).
  3. 제2항에서,
    상기 그래픽 처리 장치는,
    상기 비정상 상태인 운영 체제가 호스트 운영 체제로 판단되면, 상기 비정상 상태인 운영 체제가 재부팅을 완료할때까지 구성을 중지하는, 시스템 온-칩(SoC).
  4. 제1항에서,
    상기 복수의 중앙 처리 장치는,
    제1 스탠드얼론(Stand alone) 운영 체제를 실행하는 제1 중앙 처리 장치, 그리고
    제2 스탠드얼론 운영 체제를 실행하는 제2 중앙 처리 장치를 포함하고,
    상기 적어도 하나의 상태 모니터링 장치는,
    상기 제1 중앙 처리 장치에 연결되어, 상기 제1 스탠드얼론 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는 제1 상태 모니터링 장치, 그리고
    상기 제2 중앙 처리 장치에 연결되어, 상기 제2 스탠드얼론 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는 제2 상태 모니터링 장치
    를 포함하는, 시스템 온-칩(SoC).
  5. 제1항에서,
    상기 복수의 중앙 처리 장치는,
    스탠드얼론 운영 체제를 실행하는 제1 중앙 처리 장치, 그리고
    하이퍼바이저 프로그램, 그리고 상기 하이퍼바이저 프로그램 기반으로 적어도 하나의 게스트 운영 제제를 실행하는 제2 중앙 처리 장치를 포함하고,
    상기 적어도 하나의 상태 모니터링 장치는,
    상기 제1 중앙 처리 장치에 연결되어, 상기 스탠드얼론 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는 제1 상태 모니터링 장치를 포함하며,
    상기 하이퍼바이저 프로그램은,
    상기 적어도 하나의 게스트 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는, 시스템 온-칩(SoC).
  6. 제1항에서,
    상기 복수의 중앙 처리 장치는,
    제1 스탠드얼론 운영 체제를 실행하는 제1 중앙 처리 장치, 그리고
    제2 스탠드얼론 운영 체제, 하이퍼바이저 프로그램, 그리고 상기 하이퍼바이저 프로그램 기반으로 적어도 하나의 게스트 운영 체제를 실행하는 제2 중앙 처리 장치를 포함하고,
    상기 적어도 하나의 상태 모니터링 장치는,
    상기 제1 중앙 처리 장치에 연결되어, 상기 제1 스탠드얼론 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는 제1 상태 모니터링 장치, 그리고
    상기 제2 중앙 처리 장치에 연결되어, 상기 제2 스탠드얼론 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는 제2 상태 모니터링 장치를 포함하고,
    상기 하이퍼바이저 프로그램은,
    상기 적어도 하나의 게스트 운영 체제의 실행 상태 정보를 상기 그래픽 처리 장치로 전달하는, 시스템 온-칩(SoC).
  7. 시스템 온-칩(System on chip, SoC)에 탑재된 그래픽 처리 장치(Graphics Processing Unit, GPU)의 동작 방법으로서,
    적어도 두개의 중앙 처리 장치(Central Processing Unit, CPU)로부터 각 중앙 처리 장치에서 실행된 운영 체제(Operating System)들의 실행 상태 정보를 수집하는 단계,
    상기 실행 상태 정보에 기초하여 비정상 상태로 동작하는 운영 체제가 있는지 판단하는 단계, 그리고
    비정상 상태로 동작하는 운영 체제의 기 작업을 정상적으로 종료 처리하고, 상기 비정상 상태로 동작하는 운영 체제의 재부팅이 완료될때까지 대기하는 단계를 포함하고,
    상기 그래픽 처리 장치는,
    상기 운영 체제들이 요구한 작업들을 처리하는 공유 동작을 수행하고,
    상기 실행 상태 정보는,
    적어도 하나의 중앙 처리 장치에 연결된 상태 모니터링 장치와 연결된 버스 인터페이스를 통하여 수집되는, 그래픽 처리 장치의 동작 방법.
  8. 제7항에서,
    상기 운영 체제들 중 하나는 호스트 운영 체제로 동작하고,
    상기 판단하는 단계 이후,
    상기 비정상 상태로 동작하는 운영 체제가 호스트 운영 체제인 경우, 상기 호스트 운영 체제의 재부팅이 완료될때까지 그래픽 처리 장치의 구성을 중지하는, 그래픽 처리 장치의 동작 방법.
  9. 제7항에서,
    상기 실행 상태 정보는,
    임의의 중앙 처리 장치에서 실행된 하이퍼바이저로부터 수집되며,
    상기 하이퍼바이저가 실행한 적어도 하나의 게스트 운영 체제의 실행 상태를 포함하는, 그래픽 처리 장치의 동작 방법.
  10. 제7항에서,
    상기 실행 상태 정보는,
    적어도 하나의 중앙 처리 장치에 연결된 상태 모니터링 장치와 연결된 버스 인터페이스를 통하여 수집된 적어도 하나의 스탠드얼론 운영 체제의 실행 상태 정보와,
    임의의 중앙 처리 장치에서 실행된 하이퍼바이저로부터 수집된 적어도 하나의 게스트 운영 체제의 실행 상태를 포함하는, 그래픽 처리 장치의 동작 방법.
PCT/KR2020/016794 2019-12-23 2020-11-25 멀티-마스터를 지원하는 그래픽 처리 장치를 공유하는 시스템 온 칩 및 그래픽 처리 장치의 동작 방법 WO2021132905A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE112020006298.8T DE112020006298T5 (de) 2019-12-23 2020-11-25 Ein-Chip-System zum Teilen einer einen Multi-Master unterstützenden Grafikverarbeitungseinheit, und Verfahren zum Betreiben einer Grafikverarbeitungseinheit
US17/778,961 US20230024607A1 (en) 2019-12-23 2020-11-25 System-on-chip for sharing graphics processing unit that supports multimaster, and method for operating graphics processing unit
JP2022537810A JP7444993B2 (ja) 2019-12-23 2020-11-25 マルチマスターを支援するグラフィック処理装置を共有するシステムオンチップおよびグラフィック処理装置の動作方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020190173272A KR102275529B1 (ko) 2019-12-23 2019-12-23 멀티-마스터를 지원하는 그래픽 처리 장치를 공유하는 시스템 온 칩 및 그래픽 처리 장치의 동작 방법
KR10-2019-0173272 2019-12-23

Publications (1)

Publication Number Publication Date
WO2021132905A1 true WO2021132905A1 (ko) 2021-07-01

Family

ID=76575283

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2020/016794 WO2021132905A1 (ko) 2019-12-23 2020-11-25 멀티-마스터를 지원하는 그래픽 처리 장치를 공유하는 시스템 온 칩 및 그래픽 처리 장치의 동작 방법

Country Status (5)

Country Link
US (1) US20230024607A1 (ko)
JP (1) JP7444993B2 (ko)
KR (1) KR102275529B1 (ko)
DE (1) DE112020006298T5 (ko)
WO (1) WO2021132905A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006201919A (ja) * 2005-01-19 2006-08-03 Yoichi Furugaki マルチブートコンピュータ
KR20090016286A (ko) * 2007-08-10 2009-02-13 엘지전자 주식회사 컴퓨터 시스템 및 그 부팅제어방법
KR20120054027A (ko) * 2009-07-27 2012-05-29 어드밴스드 마이크로 디바이시즈, 인코포레이티드 프로세서들에 걸쳐 데이터-병렬 쓰레드들을 지닌 프로세싱 로직을 매핑하는 방법
JP2014203230A (ja) * 2013-04-04 2014-10-27 三菱電機株式会社 計算機システム、計算機システムの割込み処理プログラム及び計算機システムの割込み処理方法
KR101694302B1 (ko) * 2013-03-11 2017-01-23 한국전자통신연구원 이기종 멀티코어 프로세서 시스템의 관리 장치 및 방법

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8239938B2 (en) * 2008-12-08 2012-08-07 Nvidia Corporation Centralized device virtualization layer for heterogeneous processing units
WO2011011668A1 (en) 2009-07-24 2011-01-27 Advanced Micro Devices, Inc. Determining performance sensitivities of computational units
US8370605B2 (en) * 2009-11-11 2013-02-05 Sunman Engineering, Inc. Computer architecture for a mobile communication platform
US8650565B2 (en) * 2009-12-14 2014-02-11 Citrix Systems, Inc. Servicing interrupts generated responsive to actuation of hardware, via dynamic incorporation of ACPI functionality into virtual firmware
EP3224712B1 (en) * 2014-11-24 2020-12-02 Intel Corporation Support for application-transparent, highly-available gpu-computing with virtual machine (vm)-checkpointing
KR102507114B1 (ko) * 2016-06-08 2023-03-07 삼성전자주식회사 복수의 운영체제들의 화면을 통합하여 표시하는 방법 및 그 전자 장치
CN109690482A (zh) * 2016-09-05 2019-04-26 华为技术有限公司 虚拟机图形处理器的分配
CN109324903B (zh) * 2018-09-21 2021-03-02 深圳前海达闼云端智能科技有限公司 用于嵌入式系统的显示资源调度方法及装置
GB2593730B (en) * 2020-03-31 2022-03-30 Imagination Tech Ltd Hypervisor removal

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006201919A (ja) * 2005-01-19 2006-08-03 Yoichi Furugaki マルチブートコンピュータ
KR20090016286A (ko) * 2007-08-10 2009-02-13 엘지전자 주식회사 컴퓨터 시스템 및 그 부팅제어방법
KR20120054027A (ko) * 2009-07-27 2012-05-29 어드밴스드 마이크로 디바이시즈, 인코포레이티드 프로세서들에 걸쳐 데이터-병렬 쓰레드들을 지닌 프로세싱 로직을 매핑하는 방법
KR101694302B1 (ko) * 2013-03-11 2017-01-23 한국전자통신연구원 이기종 멀티코어 프로세서 시스템의 관리 장치 및 방법
JP2014203230A (ja) * 2013-04-04 2014-10-27 三菱電機株式会社 計算機システム、計算機システムの割込み処理プログラム及び計算機システムの割込み処理方法

Also Published As

Publication number Publication date
JP2023510130A (ja) 2023-03-13
KR20210081079A (ko) 2021-07-01
KR102275529B1 (ko) 2021-07-09
DE112020006298T5 (de) 2022-12-01
JP7444993B2 (ja) 2024-03-06
KR102275529B9 (ko) 2021-10-27
US20230024607A1 (en) 2023-01-26

Similar Documents

Publication Publication Date Title
WO2014200162A1 (en) Processor module, server system and method of controlling processor module
US7346792B2 (en) Method and system for managing peripheral connection wakeup in a processing system supporting multiple virtual machines
WO2013133621A1 (ko) 이종의 운영체제를 사용하는 가상화 시스템의 전력 관리 방법 및 장치
US20140068317A1 (en) Peripheral device sharing in multi host computing systems
EP2275926A2 (en) Method and apparatus to attain direct communication between accelerator and instruction sequencer
US20100138208A1 (en) Virtual machine system and method for controlling interrupt thereof
US7814496B2 (en) Method and system for replicating schedules with regard to a host controller for virtualization
WO2011105860A2 (en) Method and apparatus for generating minimum boot image
US20150033225A1 (en) Operating system switching method and apparatus
CN112148421A (zh) 虚拟机迁移的方法以及装置
EP4195020A1 (en) Computer device, abnormality processing method and interrupt processing method
US9715403B2 (en) Optimized extended context management for virtual machines
US8209686B2 (en) Saving unsaved user process data in one or more logical partitions of a computing system
JPH0754471B2 (ja) デ−タ処理装置
US20200150996A1 (en) Dynamic control of halt polling based on receiving a monitoring instruction executed by a guest
WO2020162715A1 (en) Electronic device, storage medium, and method for process scheduling
WO2021132905A1 (ko) 멀티-마스터를 지원하는 그래픽 처리 장치를 공유하는 시스템 온 칩 및 그래픽 처리 장치의 동작 방법
EP3025230A1 (en) Operating system switching method and apparatus
JP5328410B2 (ja) 被起動オペレーティングシステム（ｏｓ）動作計算機、計算機のｏｓ起動方法およびｏｓ起動プログラム
TW201433981A (zh) 多核心處理器及其相關控制方法與電腦系統
WO2021132904A1 (ko) 이종의 멀티 cpu를 운용하는 시스템-온-칩 및 그 동작 방법
US10481936B2 (en) Efficient virtual machine memory monitoring with hyper-threading
KR102211853B1 (ko) 이종의 멀티 cpu가 탑재된 시스템-온-칩 및 cpu 리부팅을 제어하는 방법
US20120284711A1 (en) Method and Arrangement for Configuring a Resource for a Virtual Runtime Environment
WO2020213853A1 (ko) Plc 시스템 및 이의 입출력 리프레시 주기 제어방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20906118

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022537810

Country of ref document: JP

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 20906118

Country of ref document: EP

Kind code of ref document: A1