As the VMID of the GPU task container for virtualization

Abstract

Systems, devices, and methods for abstracting tasks in a virtual memory identifier (VMID) container are disclosed. A processor coupled to a memory executes multiple parallel tasks including a first task. In response to detecting one or more instructions of the first task corresponding to a first operation, the processor retrieves a first identifier (ID) for uniquely identifying the first task, wherein the first ID is transparent to the first task. The processor then maps the first ID to a second ID and / or a third ID. The processor completes the first operation by identifying the first task to at least a first data structure using the second ID and / or the third ID. In one implementation, the first operation is a memory access operation, and the first data structure is a set of page tables. Moreover, in one implementation, the second ID identifies a first application of the first task, and the third ID identifies a first operating system (OS) of the first task.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a VMID as a GPU task container for virtualization. Background Art

[0002] Due to the performance per watt and cost of modern graphics processing units (GPUs), the desire to use GPUs for general computing has recently become more prevalent. The computing power of GPUs has been growing at a rate that exceeds the computing power of corresponding central processing unit (CPU) platforms. Combined with the surge in the mobile computing market (e.g., laptops, mobile smartphones, tablets) and supporting server / enterprise systems, this growth is used to achieve a quality consistent with the desired user experience. Therefore, the combined use of CPUs and GPUs to execute workloads with data-parallel content is becoming a widely used technology.

[0003] GPUs exploit massive thread-level parallelism to achieve high instruction throughput. This high throughput helps make GPUs an indispensable computing resource in many different paradigms. In many types of computing environments, multiple applications share a single processing unit. Executing multiple applications simultaneously from one or more operating systems requires various support mechanisms in hardware and software. One key mechanism is virtual memory, which manages and protects the address space of each application running on the computer. However, modern GPUs lack support for executing multiple applications in parallel. As a result, GPUs suffer from high performance overhead when running multiple parallel applications. Summary of the invention

[0004] The present application provides a graphics processing unit in a first aspect, the graphics processing unit comprising: a scheduler unit; and a plurality of computing units; wherein the graphics processing unit, GPU, is configured to: receive a first task and a second task to be scheduled to be executed on the GPU from a central processing unit; retrieve an original identifier of the first task, which identifies at least a portion of a source hierarchy associated with the first task, and retrieve an original identifier of the second task, which identifies at least a portion of a source hierarchy associated with the second task; create a first identifier for the first task and create a second identifier for the second task, wherein the first identifier and the second identifier The invention relates to a method for obtaining a first task and a second task in a computing unit comprising: receiving a first identifier of the first task and mapping the first identifier to the original identifier of the first task, the original identifier identifying the at least a portion of the source hierarchy associated with each corresponding task; using the first identifier and the second identifier to simultaneously execute the first task and the second task on the plurality of computing units; in response to detecting that a first operation of the first task requires identification of a source of the first task: receiving the first identifier of the first task; mapping the first identifier to the original identifier of the first task, which identifies the at least a portion of the source hierarchy of the first task; and performing access to the first data structure by identifying the first task using the original identifier of the first task to complete the first operation.

[0005] In one possible implementation, the GPU is configured to access a mapping table to map the first identifier to the original identifier of the first task.

[0006] In one possible implementation, the original identifier of the first task identifies one or more of the following: an operating system identifier, a virtual function identifier, a virtual memory identifier, and an application program.

[0007] In a possible implementation manner, each of the first task and the second task corresponds to a different operating system.

[0008] In one possible implementation, the first operation is a memory access operation, and the first data structure is a set of page tables.

[0009] In one possible implementation, the GPU is further configured to: maintain the mapping table at each boundary between the GPU and each component outside the GPU.

[0010] In one possible implementation, the GPU is configured to access: a memory storing program instructions of a plurality of tasks, wherein the plurality of tasks include the first task and the second task.

[0011] In a second aspect, the present application provides a method for use in a graphics processing unit (GPU), the method comprising: receiving a first task and a second task to be scheduled for execution on the GPU from a central processing unit; retrieving an original identifier of the first task, which identifies at least a portion of a source hierarchy associated with the first task, and retrieving an original identifier of the second task, which identifies at least a portion of the source hierarchy associated with the second task; creating a first identifier for the first task and a second identifier for the second task, wherein the first identifier and the second identifier uniquely identify each corresponding task without identifying the at least a portion of the source hierarchy associated with each corresponding task; executing the first task and one or more other tasks simultaneously; in response to detecting one or more instructions of the first task corresponding to a first operation and determining that the first operation is an operation that requires identification of the source of the first task: receiving the first identifier of the first task; mapping the first identifier to the original identifier of the first task, which identifies at least a portion of the source hierarchy of the first task; and performing access to a first data structure by identifying the first task using the original identifier of the first task to complete the first operation.

[0012] In a possible implementation, the method further includes the GPU accessing a mapping table to map the first identifier to the original identifier of the first task.

[0013] In one possible implementation, the original identifier of the first task identifies one or more of the following: an operating system identifier, a virtual function identifier, a virtual memory identifier, and an application program.

[0014] In a possible implementation manner, each of the first task and the second task corresponds to a different operating system.

[0015] In one possible implementation, the first operation is a memory access operation, and the first data structure is a set of page tables.

[0016] In one possible implementation, the method further includes: maintaining the mapping table at each boundary between the GPU and each component external to the GPU; and accessing the mapping table using the first identifier to retrieve the second identifier.

[0017] In one possible implementation, the first identifier is a container identifier, and wherein the method comprises preventing a task having the first container identifier from accessing data of a task having the second container identifier. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Advantages of the methods and mechanisms described herein may be better understood by referring to the following description in conjunction with the accompanying drawings, in which:

[0019] Figure 1 is a block diagram of one implementation of a computing system.

[0020] Figure 2 is a block diagram of another implementation of a computing system.

[0021] Figure 3 A block diagram illustrating one implementation of a virtual environment for a GPU.

[0022] Figure 4 A block diagram illustrating one implementation of a GPU.

[0023] Figure 5 A block diagram illustrating one implementation of a processor having a computation pipeline.

[0024] Figure 6 A block diagram illustrating one implementation of abstracting tasks in a virtual memory identifier (VMID) container.

[0025] Figure 7 A block diagram illustrating one implementation of a computing system.

[0026] Figure 8 One implementation of a mapping table for mapping container IDs to OS or VF IDs is shown.

[0027] Fig. 9 is a generalized flow chart illustrating one implementation of a method for abstracting tasks using container IDs.

[0028] Fig.10 is a generalized flow chart illustrating one implementation of a method for a scheduler to generate a container ID for a task. DETAILED DESCRIPTION

[0029] In the following description, numerous specific details are set forth to provide a thorough understanding of the methods and mechanisms presented herein. However, it will be appreciated by those of ordinary skill in the art that various implementations may be practiced without these specific details. In some cases, well-known structures, components, signals, computer program instructions, and techniques are not shown in detail to avoid confusion with the methods described herein. It should be understood that in order to make the description simple and clear, the elements shown in the drawings may not be drawn to scale. For example, the size of some elements may be enlarged relative to other elements.

[0030] Various systems, devices, and methods for abstracting tasks in a virtual memory identifier (VMID) container are disclosed herein. A processor coupled to a memory executes multiple parallel tasks including a first task. In response to detecting one or more instructions of the first task corresponding to a first operation, the processor retrieves a first identifier (ID) for uniquely identifying the first task, wherein the first ID is transparent to the first task. The processor then maps the first ID to a second ID and / or a third ID. The processor completes the first operation by identifying the first task to at least a first data structure using the second ID and / or the third ID. In one implementation, the first operation is a memory access operation, and the first data structure is a set of page tables. Moreover, in one implementation, the second ID identifies a first application of the first task, and the third ID identifies a first operating system (OS) of the first task.

[0031] Reference now Figure 1 , a block diagram of one implementation of a computing system 100 is shown. In one implementation, the computing system 100 includes at least processors 105A-N, an input / output (I / O) interface 120, a bus 125, one or more memory controllers 130, a network interface controller (NIC) 135, and one or more memory devices 140. In other implementations, the computing system 100 includes other components and / or the computing system 100 is arranged in a different manner. Processors 105A-N represent any number of processors included in the system 100. In one implementation, processor 105A is a general-purpose processor, such as a central processing unit (CPU). In one implementation, processor 105N is a data parallel processor with a highly parallel architecture. Data parallel processors include graphics processing units (GPUs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and the like. In some implementations, processors 105A-N include multiple data parallel processors.

[0032] The one or more memory controllers 130 represent any number and type of memory controllers accessible by the processors 105A-N and I / O devices (not shown) coupled to the I / O interface 120. The one or more memory controllers 130 are coupled to any number and type of one or more memory devices 140. The one or more memory devices 140 represent any number and type of memory devices. For example, the type of memory in the one or more memory devices 140 includes dynamic random access memory (DRAM), static random access memory (SRAM), NAND flash memory, NOR flash memory, ferroelectric random access memory (FeRAM), or other memory.

[0033] The I / O interface 120 represents any number and type of I / O interfaces (e.g., a peripheral component interconnect (PCI) bus, a PCI extension (PCI-X), a PCIE (PCI Express) bus, a Gigabit Ethernet (GBE) bus, a universal serial bus (USB)). Various types of peripheral devices (not shown) are coupled to the I / O interface 120. Such peripheral devices include (but are not limited to) a display, a keyboard, a mouse, a printer, a scanner, a joystick or other type of game controller, a media recording device, an external storage device, a network interface card, etc. The network interface controller (NIC) 135 receives and sends network messages across the network 145.

[0034] The network 145 represents any type of network or combination of networks, including wireless connections, direct local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), intranets, the Internet, wired networks, packet switching networks, fiber optic networks, routers, storage area networks, or other types of networks. Examples of LANs include Ethernet networks, fiber distributed data interface (FDDI) networks, and token ring networks. In various implementations, the network 145 also includes remote direct memory access (RDMA) hardware and / or software, transmission control protocol / Internet protocol (TCP / IP) hardware and / or software, routers, repeaters, switches, power grids, and / or other components.

[0035] In various implementations, computing system 100 is a computer, a laptop, a mobile device, a game console, a server, a streaming device, a wearable device, or any of a variety of other types of computing systems or devices. It should be noted that the number of components of computing system 100 varies from implementation to implementation. For example, in other implementations, there are more than 100 components in the example. Figure 1 It should also be noted that in other implementations, the computing system 100 includes a greater or lesser number of each component shown in FIG. Figure 1 Other components not shown in FIG. In addition, in other implementations, by Figure 1 The computing system 100 may be constructed in other ways different from the one shown in FIG.

[0036] Now turn to Figure 2, a block diagram of another implementation of a computing system 200 is shown. In one implementation, system 200 includes a GPU 205, a system memory 225, and a local memory 230. System 200 also includes other components, which are not shown to avoid cluttering the figure. GPU 205 includes at least a command processor 235, a scheduling unit 250, compute units 255A-N, a memory controller 220, a global data sharing 270, a level 1 (L1) cache 265, and a level 2 (L2) cache 260. Although Figure 2 255A-N also include one or more caches and / or local memories within each computing unit 255A-N. In other implementations, GPU 205 includes other components, omitting one or more of the components shown, having multiple examples of components, but in some embodiments, the GPU 205 may include other components, omitting one or more of the components shown, or providing multiple examples of components. Figure 2 Only one example is shown and / or the organization may be in another suitable manner.

[0037] In various implementations, computing system 200 executes any of various types of software applications. In one implementation, as part of executing a given software application, a host CPU (not shown) of computing system 200 initiates a task to be executed on GPU 205. Command processor 235 receives the task from the host CPU and issues the task to scheduling unit 250 for scheduling on computing units 255A-N. In one implementation, when scheduling unit 250 schedules a given task on computing units 255A-N, scheduling unit 250 generates a unique container ID for the given task by hashing an operating system (OS) or virtual function (VF) identifier (ID) with a virtual memory (VM) ID of the given task. Threads within tasks executed on computing units 255A-N access various data structures internal and external to computing system 200. When a thread accesses a data structure external to computing system 200, the container ID is mapped to a VFID and / or VMID, where the VFID and / or VMID are used to identify the thread to the external data structure.

[0038] Now go to Figure 3, a block diagram of an implementation of a virtual environment 300 for a GPU is shown. A GPU is a massively parallel machine capable of supporting multiple parallel tasks. The GPU is used to process graphics and / or computational workloads in various applications. For graphics workloads, the GPU includes a deep hybrid pipeline that includes fixed-function hardware and programmable shaders. A typical workload source hierarchy for a GPU includes an operating system (OS) and virtual functions (VFs) 310A-B, applications 308A-N, one or more queues 306A, draw calls, and dispatch levels. Each queue 306A includes any number of graphics tasks 302A and / or computational tasks 304A. When multitasking is supported, multiple workloads from various sources may exist on the GPU simultaneously.

[0039] When executing multiple different types of parallel applications on the GPU, each different workload will be marked to identify and manage the workload to implement various functions. For example, each different workload is marked for synchronization and reset purposes to implement memory management techniques and structures, manage interrupts, and implement other functions. In one implementation, each different workload is identified using a container ID to distinguish the workload from other workloads. In one implementation, the container ID is created based on a hash of the OS or VF ID and the VMID. This enables the GPU to support multiple parallel queues, applications, drawing, and dispatching from different guest OSes. In other implementations, the container ID is created based on other types of functions and / or from other types of values.

[0040] Although several discussions presented herein identify features of a GPU, it should be understood that the same techniques are applicable to other types of processors with parallel execution capabilities (e.g., multi-core CPUs, FPGAs, ASICs, DSPs). Therefore, throughout this disclosure, when a technique is described as being performed by or implemented on a GPU, it should be understood that the technique can also be performed on other types of processors.

[0041] Now go to Figure 4, a block diagram of an implementation of a GPU 400 is shown. In one implementation, the GPU 400 includes a graphics pipeline 410 coupled to a memory subsystem 420. In one implementation, the graphics pipeline 410 includes multitasking support in each pipeline stage. The front end 425 includes various queues for storing incoming tasks that have been forwarded to the graphics pipeline 410. The geometry engine 430 uses draw call commands to perform rendering of primitives for different tasks being executed on the graphics pipeline 410. The shader engine 435 implements various shader levels involved in rendering graphics. In one implementation, the pixel engine 440 is called to calculate output information and write the results to the output surface after dividing the image being rendered into a grid of boxes or tiles in screen space. In some implementations, the pixel engine 440 calculates the values ​​of vertex attributes to be interpolated on the rasterized object. In other implementations, the graphics pipeline 410 includes other levels or engines and / or each engine performs other types of operations.

[0042] Typically, the GPU includes pipeline support for multi-tasking to handle the order and dependency requirements of each stage. This means that each stage of the graphics pipeline 410 performs a separate task (e.g., task 450A on the geometry engine 430, task 450B on the shader engine 435, task 450C on the pixel engine 440). In one implementation, the graphics pipeline 410 is configured to support independent and parallel graphics tasks. In this implementation, the source level details are obscured by each stage of the GPU. Independent and parallel graphics tasks of the graphics pipeline are supported by using a container ID to distinguish each task from other parallel tasks executed on the stage.

[0043] Reference Figure 5 , a block diagram of one implementation of a processor 500 having a computation pipeline 505 is shown. In one implementation, the processor 500 includes at least the computation pipeline 505 coupled to a memory subsystem 510. In one implementation, the processor 500 is a GPU. In other implementations, the processor 500 is any of a variety of other types of processing units (e.g., FPGA, ASIC, DSP, multi-core CPU).

[0044] The computing pipeline 505 includes a front end 515 coupled to a shader engine 520. The computing pipeline 505 includes vertical and / or horizontal partitioning to enable simultaneous execution of tasks 525A-D. For example, in one implementation, task 525A is started on the shader engine 520, and other tasks are then started in subsequent clock cycles. In another implementation, tasks 525B-D are started and executed simultaneously on the shader engine 520. In this implementation, the shader engine 520 is partitioned vertically to enable simultaneous execution of multiple tasks. Vertical partitioning refers to the processing unit and processing logic of the shader engine 520 maintaining the state of multiple tasks and / or the ability to operate multiple tasks in the same clock cycle. In one implementation, a container ID is used to identify a separate task, wherein each different task has a unique container ID.

[0045] In one implementation, each level of the computing pipeline 505 is partitioned vertically. For example, the front end 515 includes a queue that allows multiple different tasks to be started and run simultaneously. Moreover, the shader engine 520 includes vertical partitions to allow multiple computing tasks to be executed simultaneously. The front end 515 and the shader engine 520 can execute workloads from multiple sources simultaneously. In one implementation, when executing these individual tasks, each level or partition in the computing pipeline 505 is unaware of the source hierarchy of the task. In this implementation, the source hierarchy details are only used when the task traverses the boundary of the processor 500.

[0046] Now go to Figure 6 , a block diagram of an implementation of abstracting tasks in a virtual memory identifier (VMID) container is shown. In one implementation, VMID 602 ​​is typically used for memory management operations to distinguish between applications executed on a processor. However, in another implementation, instead of VMID 602, a task container ID 604 is used to abstract the source hierarchy of the executed task. In various implementations, the processor does not need to identify the source of the task during execution. Instead, the processor only needs to identify the source when interacting with external components or external data structures. In one implementation, container ID 604 is used to bundle memory data structures. In this implementation, the processor provides memory protection by not allowing one container ID to access the memory contents of another container ID.

[0047] In one implementation, container ID 604 is managed by a hardware mechanism and is transparent to the software layers above the hardware execution level. The remaining software layers continue to use existing source tracking mechanisms. These existing mechanisms include OS ID, process ID, queue ID, etc. In one implementation, task tags and source levels are only related at the boundary from the processor to the external components. For example, synchronous tasks such as terminal and reset operations will reference the task source. Moreover, memory transactions outside the processor will use the task source to map to the correct memory management data structure (e.g., page table). In addition, interrupt processing is tracked on a per-source basis to identify the currently executing task to be interrupted. In addition, peripheral component interconnect high-speed (PCI-e) bus device function resolution is tracked on a per-source basis to determine the source of virtual or physical functions. Other types of operations performed at the boundary of the processor to track the task source are also possible and expected.

[0048] In one implementation, a mapping table 608 is maintained at each boundary between a processor and an external component. The mapping table maps a task's container ID 604 to an operating system (OS) ID or virtual function (VF) ID 606, a process ID, or other. Using the container ID 604 to identify the source of a task enables parallel rendering and dispatching on a processor, queues, applications, virtual functions, and the OS. Entries 610, 612, 614, and 616 represent any number of entries in the mapping table 608. In one implementation, the mapping table 608 has 16 entries, while in other implementations, the mapping table 608 includes other numbers of entries.

[0049] Reference now Figure 7 , a block diagram of an implementation of a computing system 700 is shown. In one implementation, the computing system 700 uses container IDs to track tasks in a multi-task parallel execution environment. In order to track tasks using container IDs, the system 700 includes a plurality of mapping tables (MTs) 725A-D to map container IDs to source hierarchies of tasks. Each MT 725A-D includes any number of entries, where the number of entries varies depending on the implementation.

[0050] In one implementation, the system 700 includes a system on chip (SoC) 705 coupled to a memory subsystem 730 and input / output (I / O) devices 740A-B. The I / O devices 740A-B represent any number and type of peripheral devices. It should be noted that in other implementations, the system 700 also includes other components, which are not shown to avoid confusing the drawings. The SoC 705 includes at least processor cores 710A-N, an I / O structure 715, a memory management unit 720, and an interrupt controller 735. In one implementation, the I / O structure 715 includes mapping tables 725A-B corresponding to the I / O devices 740A-B. Moreover, the MMU 720 and the interrupt controller 735 include mapping tables 725C-D, respectively. The mapping table 725C is used to map the container ID to the source level of the task so that the appropriate set of page tables can be accessed, and the mapping table 725D is used to map the container ID to the corresponding source to deliver the interrupt. In one implementation, the different MTs 725A-D are synchronized so that the entries of each MT match the entries of the other MTs. Thus, in this implementation, when an existing entry is deleted from a given MT 725A-D to make room for a new entry of a different container ID, the other MTs 725A-D are then notified and updated to match the given MT 725A-D.

[0051] Now go to Figure 8 , shows one implementation of a mapping table 800 for mapping a container ID to an OS or VF ID. In one implementation, a processor (e.g., Figure 2 The GPU 205 of the embodiment of the present invention includes one or more copies of a mapping table 800 for mapping container IDs to OS / VF IDs and VMIDs. The mapping table 800 includes a container ID field 805, an OS / VF ID field 810, and a VMID field 815. In other implementations, the mapping table 800 includes other fields and / or is organized in a different manner. A lookup of the mapping table 800 is performed using the container ID of a given task to find a matching OS / VF ID and VMID for the given task.

[0052] When it is necessary to identify the source of a task to access a given data structure or interact with an external component, the processor uses the mapping table 800 to resolve the given container ID into the OS or VF ID and VMID of the task. The OS or VF ID and / or VMID are then used to identify the source of the task to complete a specific type of operation. For example, a virtual to physical address translation is performed by accessing a specific set of page tables for a given container ID. In another example, by using the mapping table 800 to resolve the container ID into the OS / VF ID and VMID, a specific task is identified for determining where to pass the interrupt.

[0053] In one implementation, mapping table 800 has a limited number of entries. If mapping table 800 is full and a new task is started on the processor, the processor will exit, suspend or wait to complete an existing entry in mapping table 800, thereby making room for the new entry of the new task. In some implementations, the processor maintains multiple copies of mapping table 800, wherein a copy of mapping table 800 is stored at each boundary point of the processor. In these implementations, the processor synchronizes the mapping table to ensure that they have identical entries for the various container IDs of the currently executing task.

[0054] Reference now Fig. 9 , shows an implementation of a method 900 for abstracting tasks using container IDs. For discussion purposes, the steps and Fig.10 However, it should be noted that in various implementations of the described method, one or more of the described elements are performed simultaneously, in a different order than shown, or are omitted entirely. Other additional elements are also performed when necessary. Any of the various systems or devices described herein is configured to implement method 900.

[0055] The processor performs a first task and one or more other tasks simultaneously (box 905). In one implementation, the processor is a GPU. While executing the first task, the processor detects one or more instructions corresponding to a first operation (box 910). In one implementation, the first operation is a memory access operation. In another implementation, the first operation is an operation for a component external to the processor. In another implementation, the first operation is an operation that requires identification of the source of the first task. In another implementation, the first operation is a graphics operation involving rendering one or more pixels for display. In this implementation, as part of the first operation, the processor generates one or more pixels to drive a display. In other implementations, the first operation is any of various other types of operations.

[0056] In response to detecting one or more instructions of a first task corresponding to a first operation, the processor receives a first identifier (ID) that uniquely identifies the first task, wherein the first ID does not identify the source hierarchy of the first task (box 915). In other words, the first ID is transparent to the first task. In one implementation, the first ID is a container ID. Next, the processor maps the first ID to a second ID that identifies the source hierarchy of the first task (box 920). In another implementation, the processor maps the first ID to a second ID and a third ID that together identify the source hierarchy of the first task. In this implementation, the second ID identifies the first application of the first task, and the third ID identifies the first operating system (OS) of the first task. In this implementation, the source hierarchy refers to the application, OS, and / or virtual function (VF) of the first task. In contrast, the first ID abstracts the source hierarchy of the first task.

[0057] Next, the processor completes the first operation (block 925) by using the second ID to identify the first task to perform access to the first data structure. In one implementation, the first data structure is a set of virtual to physical address translation page tables. In another implementation, the first data structure is an interrupt table. After block 925, method 900 ends. It should be noted that method 900 can be performed in parallel for multiple tasks executed simultaneously on the processor. These multiple tasks include tasks from two or more different guest OSs.

[0058] Now go to Fig.10 , shows an implementation of a method 1000 for a scheduler to generate a container ID for a task. A processor (e.g., Figure 2 A scheduler of a GPU 205 of a processor receives a task to be scheduled on one or more computing units of a processor (box 1005). The scheduler retrieves a virtual function (VF) ID and a virtual memory (VM) ID associated with the task (box 1010). In another implementation, the scheduler retrieves an operating system (OS) ID associated with the task. Next, the scheduler creates a container ID for the task based on the VFID and VMID associated with the task, wherein the container ID uniquely identifies the task (box 1015). In another implementation, the scheduler creates a unique container ID for the task based on the OS ID and VMID associated with the task. In one implementation, the scheduler creates the container ID by generating a hash of the VFID (or OS ID) and the VMID. The scheduler then tags the task with a unique container ID (box 1020). In other words, the task is now associated with a unique container ID, rather than with the VFID, OS ID, or VMID of the task. This allows the processor to support multiple parallel tasks from different guest OSs, or even from the same OS.

[0059] Next, the scheduler schedules the task to be executed on one or more computing units in response to determining that the task is ready (box 1025). During task execution, the processor accesses one or more data structures by mapping the container ID to the VFID and / or VMID (box 1030). Alternatively, in box 1030, the processor maps the container ID to the OS ID and / or VMID. Depending on the implementation, the one or more data structures include a page table, an interrupt table, and / or other data structures. After box 1030, the method 1000 ends. It should be noted that in one implementation, the method 1000 is executed in parallel for multiple tasks that are executed simultaneously on the processor. These multiple tasks include tasks from two or more different guest OSs.

[0060] In various implementations, the method and / or mechanism described herein is implemented using program instructions of a software application. For example, program instructions that can be executed by a general or special processor are contemplated. In various implementations, such program instructions are represented by a high-level programming language. In other implementations, program instructions are compiled from a high-level programming language into a binary form, an intermediate form, or other form. Alternatively, program instructions describing the behavior or design of hardware are written. Such program instructions are represented by a high-level programming language such as C. Alternatively, a hardware design language (HDL) such as Verilog is used. In various implementations, program instructions are stored on any of a variety of non-temporary computer-readable storage media. During use, a computing system can access a storage medium to provide program instructions to a computing system for program execution. Generally speaking, such a computing system includes at least one or more memories and one or more processors configured to execute program instructions.

[0061] It should be emphasized that the above implementations are only non-limiting examples of implementations. Once the above disclosure is fully understood, numerous changes and modifications will become apparent to those skilled in the art. The following claims are intended to be interpreted as covering all such changes and modifications.

Claims

1. A graphics processing unit, comprising: Scheduler unit; as well as Multiple computing units; The graphics processing unit, GPU, is configured to: receiving, from a central processing unit, a first task and a second task to be scheduled for execution on the GPU; retrieving an original identifier of the first task that identifies at least a portion of a source hierarchy associated with the first task, and retrieving an original identifier of the second task that identifies at least a portion of a source hierarchy associated with the second task; creating a first identifier for the first task and creating a second identifier for the second task, wherein the first identifier and the second identifier uniquely identify each respective task without identifying the at least a portion of the source hierarchy associated with each respective task; executing the first task and the second task simultaneously on the plurality of computing units using the first identifier and the second identifier; In response to detecting that a first operation of the first task requires identifying a source of the first task: receiving the first identifier of the first task; mapping the first identifier to the original identifier of the first task, which identifies the at least a portion of the source hierarchy of the first task; as well as The first operation is accomplished by performing access to a first data structure using the original identifier of the first task to identify the first task. 2 . The graphics processing unit of claim 1 , wherein the GPU is configured to access a mapping table to map the first identifier to the original identifier of the first task. 3 . The graphics processing unit of claim 2 , wherein the original identifier of the first task identifies one or more of: an operating system identifier, a virtual function identifier, a virtual memory identifier, and an application. 4 . The graphics processing unit of claim 3 , wherein each of the first task and the second task corresponds to a different operating system. 5 . The graphics processing unit of claim 1 , wherein the first operation is a memory access operation, and wherein the first data structure is a set of page tables.

6. The graphics processing unit of claim 2, wherein the GPU is further configured to: The mapping table is maintained at each boundary between the GPU and each component external to the GPU.

7. The graphics processing unit of any one of claims 1 to 6, wherein the GPU is configured to access: A memory storing program instructions for a plurality of tasks, wherein the plurality of tasks includes the first task and the second task.

8. A method for use in a graphics processing unit (GPU), the method comprising: receiving, from a central processing unit, a first task and a second task to be scheduled for execution on the GPU; retrieving an original identifier of the first task that identifies at least a portion of a source hierarchy associated with the first task, and retrieving an original identifier of the second task that identifies at least a portion of a source hierarchy associated with the second task; creating a first identifier for the first task and creating a second identifier for the second task, wherein the first identifier and the second identifier uniquely identify each respective task without identifying the at least a portion of the source hierarchy associated with each respective task; performing a first task and one or more other tasks simultaneously; In response to detecting one or more instructions of the first task corresponding to a first operation and determining that the first operation is an operation requiring identification of a source of the first task: receiving the first identifier of the first task; mapping the first identifier to the original identifier of the first task, which identifies the at least a portion of the source hierarchy of the first task; as well as The first operation is accomplished by performing access to a first data structure using the original identifier of the first task to identify the first task. 9 . The method of claim 8 , further comprising the GPU accessing a mapping table to map the first identifier to the original identifier of the first task.

10. The method of claim 9, wherein the original identifier of the first task identifies one or more of: an operating system identifier, a virtual function identifier, a virtual memory identifier, and an application. The method of claim 10 , wherein each of the first task and the second task corresponds to a different operating system.

12. The method of claim 8, wherein the first operation is a memory access operation, and wherein the first data structure is a set of page tables.

13. The method according to claim 9, further comprising: maintaining the mapping table at each boundary between the GPU and each component external to the GPU; as well as The mapping table is accessed with the first identifier to retrieve the second identifier.

14. The method of claim 8, wherein the first identifier is a container identifier, and wherein the method includes preventing a task having a first container identifier from accessing data of a task having a second container identifier.

Images