Graphics processing system

Abstract

A graphics processing system includes a programmable processing unit operable to execute processing programs for executing threads corresponding to work items to be processed, and a storage (74) in which respective storage regions can be allocated for temporary use by respective groups of executing threads corresponding to groups of work items being executed by the programmable processing unit while the group of executing threads is being executed. The graphics processing system further includes one or more memory region "access permission" check circuits operable to prevent access to the storage for any requesters making requests to the storage that are not executing threads of a work group for which the respective region of the storage has been allocated for use.

Description

Background Technology

[0001] The techniques described in this article relate to graphics processing systems (and graphics processors), and in particular to the operation of graphics processors / systems when using local storage devices to (temporarily) store data for execution thread groups.

[0002] Many graphics processing units (GPUs) include one or more processing (shader) cores that specifically execute programmable processing stages (often referred to as "shaders") of a graphics processing pipeline implemented by the GPU. For example, a graphics processing pipeline may include one or more, and typically all of, the following: geometry shaders, vertex shaders, and fragment (pixel) shaders. These shaders are programmable processing stages that execute shader programs on input data values ​​to generate desired output datasets (such as, in the case of fragment shaders, appropriately shaded and rendered fragment data) for processing by the rest of the graphics processing pipeline and / or for output.

[0003] It is also known to use graphics processing units (GPUs) and graphics processing pipelines, particularly GPU and GPU shader operations, to perform more general computational tasks, such as in situations requiring operations relative to a large number of distinct input data values. These operations are commonly referred to as "computational shading" operations, and several specific computational APIs (such as OpenCL and Vulkan) have been developed for situations where it is desirable to perform general computational operations using GPUs and GPU pipelines. Computational shading is used to compute arbitrary information. It can be used to process graphics-dependent data if desired, but it is also used for tasks not directly related to performing graphics processing.

[0004] When performing “shader” processing, the graphics processor shader core executes a (typically small) program for each “work item” in the output to be generated. In the case of generating graphics output (such as a render target, such as a frame to be displayed), for this purpose, a “work item” is typically a vertex or sampled position (e.g., in the case of a fragment shader). In the case of computational shading operations, each “work item” in the output being generated will be a data instance (item) in the workspace where the computational shading operation is being performed.

[0005] In graphics processor shader operations, including computational shading, each "work item" is processed by an execution thread that executes the instructions in the shader program for the "work item" under consideration.

[0006] In this type of arrangement, the workload of the graphics processor is typically subdivided into corresponding groups of work items (and corresponding execution threads), which are referred to as "workgroups." A workgroup is typically a collection of tens to hundreds of execution threads (corresponding to corresponding work items), all of which are guaranteed to coexist (i.e., have the same lifespan) and be able to communicate and synchronize with each other (e.g., using workgroup-wide barriers). These execution threads are typically, but not necessarily, short-lived, with a typical lifespan of tens to thousands of instructions.

[0007] To facilitate data sharing among threads within a workgroup, a memory region known as the "workgroup local storage" is typically allocated for a given (and each) workgroup. Threads within the workgroup can read from and write to this memory region. This memory region can be allocated from normal system memory or from on-chip resources and remains available to all threads in the workgroup for the entire workgroup's lifetime. When a workgroup reaches the end of its lifetime, the workgroup's "local storage" memory region is typically deallocated, making it available to another workgroup.

[0008] The applicant believes that when the working group is processed in the manner described above, there is still room for improvement in the operation of the graphics processor / system. Attached Figure Description

[0009] Implementations of the techniques described herein will now be described by way of example only, with reference to the accompanying drawings, wherein:

[0010] Figure 1 An exemplary graphics processing system is shown;

[0011] Figure 2 An implementation scheme of a graphics processor capable of operating in the manner described herein is illustrated schematically;

[0012] Figure 3 The shared memory of the workgroup local storage device in an implementation of the technology described herein is shown in more detail;

[0013] Figure 4 This is a flowchart illustrating the operation of the bundle manager when implementing a boundary inspection implementation based on a "trust domain";

[0014] Figure 5 This is a flowchart illustrating the corresponding boundary check operation based on a "trust domain" performed according to such an implementation scheme;

[0015] Figure 6 This is a memory diagram illustrating a memory layout according to such an embodiment;

[0016] Figure 7This is a flowchart illustrating the operation of the bundle manager when implementing another implementation of "range"-based boundary checks;

[0017] Figure 8 This is a flowchart illustrating the corresponding "scope"-based boundary check operation performed according to such an implementation scheme;

[0018] Figure 9 This is a memory diagram illustrating a memory layout according to such an embodiment;

[0019] Figure 10 Another embodiment of the technology described herein illustrates a workgroup local storage device sharing memory;

[0020] Figure 11 Another embodiment of the technology described herein illustrates a workgroup local storage device sharing memory;

[0021] Figure 12 Another embodiment of the technology described herein illustrates a workgroup local storage device sharing memory;

[0022] Figure 13 Another embodiment of the technology described herein illustrates a workgroup local storage device sharing memory;

[0023] Figure 14 Another embodiment of the technology described herein illustrates a workgroup local storage device sharing memory; and

[0024] Figure 15 A shared memory for a workgroup local storage device is shown in another embodiment of the technology described herein.

[0025] Where appropriate, similar reference numerals are used for similar elements in the accompanying drawings. Detailed Implementation

[0026] A first embodiment of the technology described herein includes a graphics processing system comprising:

[0027] A programmable processing unit capable of operating to execute a processing program for an execution thread, the execution thread corresponding to a work item to be processed by the graphics processing system;

[0028] A storage device, wherein a corresponding area of ​​the storage device can be allocated for temporary use by a corresponding execution thread group, the corresponding execution thread group corresponding to a group of work items being executed by a programmable processing unit while the execution thread group is being executed.

[0029] The graphics processing system also includes one or more memory region access permission checking circuits that control memory access to the storage device, the one or more memory region access permission checking circuits being configured to:

[0030] When a request is made to access a corresponding region of the memory device for an execution thread of a work item group being executed by a programmable processing circuit:

[0031] Determine whether the executing thread requesting access to the appropriate region of the storage device is permitted to access that region; and

[0032] When it is determined that the execution thread is not (i.e., not) permitted to access the corresponding area of ​​the storage device, the execution thread is prevented from accessing that area of ​​the storage device (which the execution thread is requesting access to).

[0033] A second embodiment of the technology described herein includes a method for operating a graphics processing system, the graphics processing system comprising:

[0034] A programmable processing unit capable of operating to execute a processing program for an execution thread, the execution thread corresponding to a work item to be processed by the graphics processing system;

[0035] Storage device, wherein a corresponding area of ​​the storage device can be allocated for temporary use by a corresponding execution thread group, the corresponding execution thread group corresponding to a group of work items being executed by a programmable processing unit while the execution thread group is being executed; and

[0036] One or more memory region access permission checking circuits that control memory access to the storage device.

[0037] The method includes:

[0038] When a request is made to access a corresponding region of the memory device for an execution thread of a work item group being executed by a programmable processing circuit:

[0039] One or more memory region access permission check circuits:

[0040] Determine whether the executing thread requesting access to the appropriate region of the storage device is permitted to access that region; and

[0041] When it is determined that the execution thread is not (i.e., not) permitted to access the corresponding area of ​​the storage device, the execution thread is prevented from accessing that area of ​​the storage device (which the execution thread is requesting access to).

[0042] The technology described herein relates to a graphics processing system (and graphics processor) that includes a programmable processing unit (“shader core”) that has access to a storage device that can be allocated for use by a “workgroup” (as discussed above) (“workgroup local storage”) executing on the programmable processing unit.

[0043] The graphics processing system described herein also includes a memory region “access permission check” circuit (or multiple such circuits controlling memory access to (different) memory of the storage device) that controls memory access to the storage device, and as will be discussed in more detail below, the memory region “access permission check” circuit is operable and configured to perform appropriate memory region “access permission check” operations such that the corresponding region of the (workgroup local) storage device can only be accessed (and only) by the execution thread of the (workgroup local) storage device region considered by the permitted access of the corresponding workgroup being executed by the programmable processing unit (wherein the memory region “access permission check” circuit is also operable and configured to prevent the execution thread from accessing the region of the storage device that the execution thread is requesting access to when it is determined that the execution thread is not (i.e., not) permitted to access the corresponding region of the storage device.

[0044] For example, it should be understood that different workgroups may typically reside in the same "trust domain" (e.g., when they come from the same application / process and / or virtual machine, etc.), but may also reside in different trust domains (e.g., when they come from different applications / processes and / or virtual machines, etc.). When different workgroups reside in different trust domains, data should not be able to leak across trust domains via workgroup local storage.

[0045] Therefore, in the implementation, (at least) when the corresponding area of ​​the storage device is currently allocated for use by a workgroup residing in a different trust domain than the workgroup that includes the execution requesting access to the area under consideration, it is determined that the execution thread is not (i.e., not) permitted to access that area of ​​the (workgroup local) storage device. This determination can be made in various suitable ways as desired.

[0046] For example, in an implementation plan, this determination can (and does) be made on a per-working-group basis.

[0047] Therefore, in the implementation scheme, when a request is made to access a corresponding area of ​​the storage device for an execution thread of a group of work items being executed by the programmable processing circuitry:

[0048] One or more memory region access permission check circuits are configured to (and executed as part of the method steps) to:

[0049] Determine whether the corresponding region of the storage device that the execution thread is requesting access to has been allocated for use by the work item group that includes the execution thread; and

[0050] When it is determined that the execution thread making the request is not an execution thread of a workgroup whose corresponding area of ​​the storage device has been allocated for its use, access to the corresponding area of ​​the storage device (which the execution thread is requesting access to) is blocked.

[0051] This means that the respective workgroup is only permitted (and can only) to access its own local storage device, and data cannot be leaked between different workgroups that are being processed simultaneously (regardless of whether these workgroups are from the same or different trust domains).

[0052] However, the applicant of this invention also recognizes that data leakage between different workgroups is acceptable as long as it is known that different workgroups come from the same trust domain. In this case, if different workgroups within the same trust domain attempt to access each other's data, this will only represent an "undefined" access (e.g., and therefore can be handled using the normal procedures for handling such "undefined" accesses of the graphics processor / system under consideration), but there is no security risk.

[0053] Therefore, in other implementations, it is possible (and indeed) to determine whether an execution thread is permitted to access a specific area of ​​the (workgroup-local) storage device it is trying to access based on each trust domain (where access is blocked if the execution thread is trying to access an area of ​​the storage device that has been allocated for use by one or more workgroups from different trust domains).

[0054] Therefore, generally speaking, a storage device is a storage device in which a corresponding area of ​​the storage device can be allocated for temporary use by a corresponding execution thread group, which corresponds to a group of work items being executed by a programmable processing unit while the execution thread group is being executed, wherein different groups of work items may reside in the same or different trust domains. In this case, in an implementation, when a request is made to access a corresponding area of ​​the storage device for an execution thread of a group of work items being executed by the programmable processing circuitry:

[0055] One or more memory region access permission check circuits are configured to (and executed as part of the method steps) to:

[0056] Determine whether the corresponding area of ​​the storage device that the execution thread is requesting access to has already been allocated for use by the work item group that includes the execution thread, or for use by another work item group within the same trust domain as the work item group that includes the execution thread; and

[0057] When it is determined that the execution thread making the request is not the execution thread of a work item group for which the corresponding area of ​​the storage device has been allocated for its use, or the execution thread of another work item group within the same trust domain, access to the corresponding area of ​​the storage device is blocked.

[0058] Therefore, according to the implementation, the memory region “access permission check”, which is an operation performed by one or more memory region “access permission check” circuits according to the technology described herein, is operable and configured such that the corresponding region of the (workgroup local) storage device can only (and only) be accessed by the execution thread of the corresponding workgroup being executed by the programmable processing unit that is in the same trust domain as the workgroup (for which the region of the (workgroup local) storage device has been allocated for use as the corresponding workgroup local storage device of the workgroup) (and in some implementations, to ensure that the corresponding region of the (workgroup local) storage device can only (and only) be accessed by the programmable processing unit as the execution thread of the corresponding workgroup being executed by the workgroup (the region of the (workgroup local) storage device has been allocated for its use)).

[0059] In this regard, as will be further described below, it should be understood that the access permissions (in implementation) in the technology described herein are defined per workgroup (or at least per “trust domain”) (e.g., not per application) and change dynamically with the start and end of a workgroup, i.e., based on temporary allocations to and as part of the (workgroup-local) storage device.

[0060] Therefore, by providing one or more such memory region “access permission check” circuits, the techniques described herein provide a (hardware-based) mechanism to prohibit memory access to a corresponding region of a (workgroup-local) storage device that has been allocated for use by a specific workgroup, for any requester that is not a (workgroup-local) storage device whose corresponding region has not been allocated for use by that specific workgroup. This can then enhance the security of the use of workgroup-local storage devices, for example, by ensuring that any “out-of-bounds” memory access (e.g., and particularly, across different trust domains) can be prevented.

[0061] Furthermore, one or more such memory region “access permission check” circuits may (and in one embodiment, indeed) be appropriately positioned along the memory access path to the (workgroup local) storage device, such that the check may (and in one embodiment, indeed) be performed for all memory accesses to the (workgroup local) storage device (based on (dynamic) memory access permissions defined for the workgroup), and in one embodiment, the check is performed automatically (in hardware) via one or more such memory region “access permission check” circuits (rather than relying on a programmer to do so).

[0062] Therefore, according to the technology described herein, when (and whenever) a request for access to a corresponding area of ​​a storage device is made by an execution thread of a work item group being executed by a programmable processing circuit via such a memory area “access permission check” circuit, the memory area “access permission check” circuit is configured to determine whether the memory access should be permitted, and in particular, and in one embodiment, by determining whether the corresponding area of ​​the storage device to which the execution thread is requesting access has been allocated for use by the work item group including the execution thread, or at least has been allocated for a work item group that is in the same trust domain as the work item group including the execution thread.

[0063] As long as the request originates from an execution thread of a work item group considering the region to be granted access (e.g., because the request originates from an execution thread within the same trust domain as the work item group to which the region of the storage device has been allocated for its use (or actually from that specific work item group)), memory region access can (and should) be granted, and the memory region "access permission check" circuitry thus permits the memory access to proceed further along the memory access path to the (workgroup-local) storage device. For example, after the memory region "access permission check" operation completes, if the request passes the memory region "access permission check" operation, the request is then further passed along the memory access path to the (workgroup-local) storage device, for example, and in an embodiment, such that the memory access request can subsequently be served, for example, by performing the requested read and / or write transactions as usual.

[0064] (It should be understood here that after the memory region “access permission check” operation is completed, various additional checks can be performed along the memory access path to the (workgroup local) storage device, and therefore even if the request passes through the memory region “access permission check” circuit, memory access can still be prohibited at different points along the memory access path to the (workgroup local) storage device.)

[0065] On the other hand, when it is determined that a request is not permitted, for example, and in an implementation, because the request is not made for an execution thread of a workgroup that has been allocated to the corresponding area of ​​the storage device for its use (or at least for another workgroup within the same trust domain), the memory region "access permission check" operation fails, and the memory region "access permission check" circuitry is thus able to operate and be configured to block access to the (workgroup-local) storage device. Therefore, the request to access the corresponding area of ​​the storage device that has been allocated for a different workgroup is blocked, and the memory region "access permission check" circuitry may alternatively respond to the request by returning a suitable empty response (or another response that does not depend on the content already stored in the considered entry (area)).

[0066] This then helps prevent different workgroups (which may reside in different trust domains) from accessing each other's data.

[0067] Therefore, the applicant correspondingly believes that the techniques described herein provide improved arrangement and operation of graphics processors (and graphics processing systems), particularly when using "workgroup local storage" as a shared storage device for execution threads in the corresponding workgroup.

[0068] The techniques described in this article are also extended to graphics processors used within graphics processing systems as described above.

[0069] Therefore, another embodiment of the technology described herein includes a graphics processor comprising:

[0070] A programmable processing unit capable of operating to execute a processing program for an execution thread, the execution thread corresponding to a work item to be processed by a graphics processor;

[0071] The graphics processor also includes one or more memory region access permission checking circuitry for controlling memory access to the storage device, wherein a corresponding region of the storage device can be allocated for temporary use by a corresponding execution thread group, the corresponding execution thread group corresponding to a group of work items being executed by the programmable processing unit while the execution thread group is being executed, and the one or more memory region access permission checking circuitry is configured to:

[0072] When a request is made to access a corresponding region of the memory device for an execution thread of a work item group being executed by a programmable processing circuit:

[0073] Determine whether the executing thread requesting access to the appropriate region of the storage device is permitted to access that region of the storage device; and

[0074] When it is determined that the execution thread is not (i.e., not) permitted to access the corresponding area of ​​the storage device, the execution thread is prevented from accessing that area of ​​the storage device (which the execution thread is requesting access to).

[0075] Correspondingly, another embodiment of the technology described herein includes a method of operating a graphics processor, the graphics processor comprising:

[0076] A programmable processing unit operable to execute a processor for an execution thread, the execution thread corresponding to a work item to be processed by the graphics processor; and

[0077] One or more memory region access permission checking circuits control memory access to the storage device, wherein corresponding regions of the storage device can be allocated for temporary use by corresponding execution thread groups, which correspond to a group of work items being executed by a programmable processing unit while the execution thread group is being executed.

[0078] The method includes:

[0079] When a request is made to access a corresponding region of the memory device for an execution thread of a work item group being executed by a programmable processing circuit:

[0080] One or more memory region access permission checking circuits determine whether an execution thread requesting access to a corresponding region of the storage device is permitted to access that region of the storage device; and

[0081] One or more memory region access permission checking circuits prevent the execution thread from accessing the corresponding region of the memory device (which the execution thread is requesting access to) when they determine that the execution thread is not (i.e., not) permitted to access the corresponding region of the memory device.

[0082] As those skilled in the art will understand, these embodiments of the technology described herein may, where appropriate, include any one or more or all of the features of the technology described herein, and in one embodiment, indeed include any one or more or all of the features of the technology described herein. Therefore, in one embodiment, the determination of whether an execution thread is permitted to access a specific area of ​​the storage device is performed on a per-workgroup or per-trust-domain basis, as explained above.

[0083] A graphics processing system can be any suitable and desired graphics processing system that includes a programmable processing unit capable of executing program instructions.

[0084] The programmable processing unit of a graphics processing system can be any suitable and desired programmable processing unit (“core”) capable of operating to execute (shader) programs.

[0085] In one embodiment, the programmable processing unit is part of the graphics processor of the graphics processing system. Therefore, in one embodiment, the system includes a graphics processor that includes a programmable processing unit. The graphics processor can be any suitable and desirable graphics processor that includes a programmable processing unit capable of executing program instructions.

[0086] A graphics processor / system may include a single programmable processing unit, or may have multiple such units. In the presence of multiple programmable processing units, each processing unit may, and indeed does, operate in a manner consistent with the techniques described herein in one embodiment.

[0087] In the presence of multiple programmable processing units, each unit can be provided as a separate circuit to other programmable processing units of the graphics processor / system, or programmable processing units can share some or all of their circuits (circuit elements).

[0088] The programmable processing unit (and each) shall, and in one embodiment, include appropriate circuitry (processing circuitry / logic) for performing the operations required by the programmable processing unit.

[0089] Therefore, the programmable processing unit (and each of them) will, for example, and in one embodiment, include an instruction execution circuit (execution engine) capable of operating and configured to execute program instructions for an execution thread. The instruction execution circuit (engine) should, and in one embodiment, include a set of at least one set of functional units (circuits) capable of operating to perform data processing operations in response to instructions being executed by the execution thread. The execution unit (engine) may include only a single functional unit, or may include multiple functional units, depending on the operations the execution unit (engine) will perform.

[0090] In one implementation, the graphics processor / system and the programmable processing unit are capable of operating to execute multiple sets (“bundles”) of multiple execution threads together, for example, in a lockstep manner (one instruction at a time).

[0091] (It should be understood here that a “workgroup” will therefore typically and in one implementation will contain multiple such execution thread groups (“bundles”). Thus, in one implementation, a “workgroup” includes multiple such execution thread groups (“bundles”), each of which has access to the workgroup (local) storage device allocated for the workgroup.)

[0092] In this context, functional units such as those of a given execution unit are configured and operable in one implementation to facilitate such thread bundle arrangements. Thus, for example, in one implementation, functional units are arranged as corresponding execution channels, and a thread bundle may contain one execution channel for each thread.

[0093] In one implementation, the graphics processor (programmable processing unit) also includes any other suitable and desired units and circuits required for the operation of the programmable processing unit, such as suitable control circuitry (control logic) for controlling the execution unit (engine) to initiate and perform desired and appropriate processing operations.

[0094] Therefore, in one implementation, the graphics processor / system (programmable processing unit) also includes appropriate thread (bundle) manager (controller) circuitry (“bundle manager”) that is operable to issue multiple bundles of threads to the execution unit (engine) for execution and to control the scheduling of the multiple bundles of threads on / to the execution unit (engine) for execution.

[0095] In one implementation, the thread (bundle) manager includes: an execution thread generator circuit that generates (produces) (multiple bundles) of threads for execution; and an execution thread scheduler circuit that schedules (multiple bundles) of threads for execution (this may be part of the thread generator).

[0096] In one embodiment, the graphics processor / system also includes and / or access to appropriate (local) storage devices (such as registers / register files, caches, etc.), and appropriate interfaces to and communication with the graphics processor / system's memory (memory system) or graphics processor / system-accessible memory (memory system) (e.g., and in an embodiment, via an appropriate cache hierarchy), and appropriate load / store units and communication paths for transferring data between the local storage devices and the graphics processor / system's memory system or graphics processor / system-accessible memory system.

[0097] In one implementation, the memory and memory system are main memory accessible to the graphics processor / system, such as memory dedicated to the graphics processor / system, or main memory of a data processing system in which the graphics processor / system is part.

[0098] Storage devices used for (temporarily) storing data of the execution thread of a workgroup in the art described herein (storage devices for "workgroup local storage devices") may be for the execution thread when executed on a programmable processing unit (graphics processor / system) or any suitable and desired storage device that can be used for the execution thread.

[0099] The storage device is intended to be a storage device (memory) through which the execution thread of the corresponding workgroup can pass values ​​to other threads in the workgroup, but the storage device (memory) is to be allocated for temporary use by the threads of the workgroup (and thus reused from one workgroup and / or process for another workgroup and / or process).

[0100] Therefore, this differs from storage devices (e.g., system memory) intended for “transferring” data values ​​between different workgroups, processes, and / or components throughout a data processing system. Instead, it is intended to be, and truly is, a local and temporary storage device (memory) for use by a workgroup and can be allocated for use by that workgroup, but once the workgroup has terminated, it will be deallocated from the workgroup in question (and made available to another workgroup).

[0101] Therefore, the storage device for "workgroup local storage" in the technology described herein is intended to be, and serves as, a "notebook-like memory" for use by a workgroup executing on a programmable processing unit.

[0102] The allocation of storage areas within the "workgroup local storage" to the corresponding workgroup being executed by the programmable processing unit can be performed in any suitable and desired manner. In one implementation, the allocation of the workgroup local storage for the graphics processor and graphics processing system under consideration is done in a normal manner.

[0103] In one implementation, a corresponding region of the storage device can (and indeed) be simultaneously assigned to multiple different workgroups, i.e., such that there will be multiple different "workgroup-local storage" regions simultaneously assigned to different workgroups within the storage device (and these multiple different workgroups may reside in different trust domains, e.g., different workgroups belonging to different applications / processes and / or virtual machines for which graphics processing is performed simultaneously). Alternatively, if desired, it may also be possible for any given workgroup within the storage device to include multiple different (separate) regions within the storage device.

[0104] The storage device used for “workgroup local storage” may include a storage device dedicated to and specifically reserved for providing “workgroup local storage” (and this is the case in one embodiment), or it may include a storage device that can be used for other purposes besides being intended to be used as “workgroup local storage” (such as for use by other processes executable by the graphics processor / system) (and this is the case in another embodiment).

[0105] In the latter case, the storage device to provide a “workgroup local storage device” will accordingly have multiple “requesters” (“subjects”) capable of accessing it, including at least execution threads and corresponding processes and circuits for using the “shared” storage device for the “workgroup local” storage device, as well as other processes and circuits for using the storage device for other purposes.

[0106] The storage device providing local storage for the workgroup can be configured as desired, for example, as a single storage unit. In one embodiment, the storage device is configured as multiple independently accessible (memory) units (e.g., to allow more than one memory access per clock cycle).

[0107] In cases where storage devices are configured across multiple (memory) banks (whether dedicated to workgroup local storage or other storage devices), then in one embodiment, each storage (memory) bank has its own accessor circuitry that controls memory accesses by the execution thread of the workgroup currently being executed by the programmable processing unit, wherein each accessor circuitry (in this embodiment) is operable and configured to operate independently (once started) for its respective memory bank. For example, each accessor circuitry may maintain a corresponding memory access (transaction) queue to be served for the execution thread of the workgroup currently being executed by the programmable processing unit associated with its respective storage (memory) bank.

[0108] A storage device may be provided in the graphics processing system as desired, which provides local storage for the workgroup.

[0109] In one embodiment, it is a local (on-chip) storage device of the graphics processor, and in another embodiment, it is a local (on-chip) storage device of the programmable processing unit of the graphics processor / system, and also on-chip with the programmable processing unit of the graphics processor / system. Therefore, in one embodiment, the storage device is a storage device that provides a faster, more efficient, and higher bandwidth path from the programmable processing unit (its instruction execution circuitry) than, for example, the (main) memory system or the memory available to the graphics processor / system.

[0110] Therefore, in one implementation, the storage device does not form part of a cache hierarchy or (main) memory (system), and in the implementation, it does not need to communicate via any communication bus outside the graphics processor and / or programmable processing unit for access by / to a workgroup executing on the programmable processing unit.

[0111] Correspondingly, in one embodiment, the system includes a graphics processor that includes both a programmable processing unit and a storage device for providing "workgroup local storage." Therefore, in one embodiment, one or more memory region "access permission check" circuits (in the case of multiple circuits, multiple such circuits are provided) are also provided locally on the programmable processing unit of the graphics processor / system and on-chip together with the programmable processing unit of the graphics processor / system, as part of the same graphics processor.

[0112] Therefore, another embodiment of the technology described herein includes a graphics processor comprising:

[0113] A programmable processing unit capable of operating to execute a processing program for an execution thread, the execution thread corresponding to a work item to be processed by a graphics processor;

[0114] A storage device, wherein a corresponding area of ​​the storage device can be allocated for temporary use by a corresponding execution thread group, the corresponding execution thread group corresponding to a group of work items being executed by a programmable processing unit while the execution thread group is being executed.

[0115] The graphics processor also includes one or more memory region access permission checking circuits that control memory access to the storage device, the one or more memory region access permission checking circuits being configured to:

[0116] When a request is made to access a corresponding region of the memory device for an execution thread of a work item group being executed by a programmable processing circuit:

[0117] Determine whether the executing thread requesting access to the appropriate region of the storage device is permitted to access that region of the storage device; and

[0118] When it is determined that the execution thread is not (i.e., not) permitted to access the corresponding area of ​​the storage device, the execution thread is prevented from accessing that area of ​​the storage device (which the execution thread is requesting access to).

[0119] Correspondingly, another embodiment of the technology described herein includes a method of operating a graphics processor, the graphics processor comprising:

[0120] A programmable processing unit capable of operating to execute a processing program for an execution thread, the execution thread corresponding to a work item to be processed by a graphics processor;

[0121] Storage device, wherein a corresponding area of ​​the storage device can be allocated for temporary use by a corresponding execution thread group, the corresponding execution thread group corresponding to a group of work items being executed by a programmable processing unit while the execution thread group is being executed; and

[0122] One or more memory region access permission checking circuits that control memory access to the storage device.

[0123] The method includes:

[0124] When a request is made to access a corresponding region of the memory device for an execution thread of a work item group being executed by a programmable processing circuit:

[0125] One or more memory region access permission check circuits are configured to:

[0126] Determine whether the executing thread requesting access to the appropriate region of the storage device is permitted to access that region of the storage device; and

[0127] When it is determined that the execution thread is not (i.e., not) permitted to access the corresponding area of ​​the storage device, the execution thread is prevented from accessing that area of ​​the storage device (which the execution thread is requesting access to).

[0128] As should be understood by those skilled in the art, these embodiments of the technology described herein may include any one or more or all of the features of the technology described herein, and in one embodiment, may indeed include any one or more or all of the features of the technology described herein.

[0129] For example, as discussed above, in the techniques described herein, a memory region access “permission check” operation is performed such that when an execution thread of a work item group being executed by a programmable processing circuit requests access to a corresponding region of the memory device: it is determined whether the execution thread is permitted to access that region of the memory device, and in one embodiment, this determination is made by determining whether the corresponding region of the memory device to which the execution thread is requesting access has already been allocated for use by the work item group including the execution thread (wherein access to the corresponding region of the memory device is then controlled based on such determination).

[0130] Correspondingly, the graphics processing system (graphics processor) includes one or more memory region “access permission” checking circuits, wherein each memory region “access permission” checking circuit is operable and configured to perform such memory region access permission checking operations on a corresponding memory access made via the memory region “access permission” checking circuit.

[0131] Based on the specific requirements of the technology described herein, a memory region access "license check" operation performed by one (or more) memory region "access license" check circuits according to the technology described herein may include any suitable and desired memory region access "license check" operation (and one (or more) memory region "access license" check circuits may be appropriately configured to perform any such memory region access "license check" operation as desired).

[0132] For example, in an implementation, the memory region access “license check” operation involves appropriate “boundary checks.” The “boundary” being checked should, and in one implementation, actually originate from the graphics processor / system (hardware) (and conversely should not originate from untrusted sources (such as instruction streams)).

[0133] However, depending on the specific requirements of the technology described in this paper, such (hardware-based) memory region boundary checks can be implemented in any suitable and desirable manner. Two main examples are envisioned.

[0134] In the first primary example, a boundary check based on an "address range" is performed, wherein when a region of a (workgroup-local) storage device is allocated for use by a specific workgroup, or for a group of workgroups from the same trust domain, an indication of the address range of a region of a (workgroup-local) storage device that has been allocated for that workgroup / trust domain is stored in a manner that allows (and does indeed) it to be associated with all execution threads generated for that workgroup / trust domain.

[0135] The indication may, and in one embodiment does, include an indication of the base (start) address and size of a region of the allocated storage device, but may also include, for example, an indication of the base (start) address and top (end) address defining the region. In some cases, for example, if non-contiguous regions of the storage device are allocated, the indication may include a set of indicators defining the base (start) and size and / or top (end) address, which define each non-contiguous region. Various arrangements will be possible in this regard.

[0136] Therefore, according to this first primary example, boundary checks based on "address ranges" can be performed either on a per-workgroup basis or on a per-trust-domain basis. In the case of performing boundary checks on a per-workgroup basis, each workgroup for which (workgroup-local) storage devices have been allocated will thus be associated with a corresponding indication of the address range of the region for which (workgroup-local) storage devices have been allocated. Correspondingly, in the case of performing boundary checks on a per-trust-domain basis, each workgroup within a particular trust-domain for which (workgroup-local) storage devices have been allocated will thus be associated with a corresponding indication of the address range of the region for which (workgroup-local) storage devices have been allocated for any (and all) workgroups from that (same) trust-domain.

[0137] Then, according to the first primary example, the memory region access “license check” operation performed on an incoming memory access for an execution thread of a specific workgroup may include determining whether the address that the memory access is requesting access to is within or outside the address range of a (workgroup-local) storage device that has been allocated for use by the specific workgroup / trust domain for which the execution thread is requesting memory access.

[0138] If an incoming memory access request requests access to an address within the address range of a region that has been allocated to a (workgroup-local) storage device belonging to the specific workgroup / trust domain for which the execution thread is requesting the memory access, then the memory region access "permission check" operation fails, and an appropriate response should be returned in this case.

[0139] Therefore, in some implementations, determining whether a region of the storage device for which an execution thread is requesting access has been allocated for use by a work item group including the execution thread includes comparing the memory address being requested with a range of memory addresses identifying the region of the storage device already allocated for use by the work item group, or in some implementations, comparing the memory address being requested with a range of memory addresses identifying the region of the storage device already allocated for use by any work item group from the same trust domain for which it is being requested. If the address requested by the execution thread for the workgroup is outside the address range of a region of the (workgroup-local) storage device already allocated for that workgroup / trust domain, the request is "out of bounds" and should therefore (and indeed will) be blocked.

[0140] However, various other examples will be possible.

[0141] For example, in the second main example, a boundary check based on an "identifier" is performed, where when a region of the (workgroup local) storage device is allocated for use by a specific workgroup, the region is associated with a corresponding identifier that is associated with the workgroup for which the region has been allocated.

[0142] For example, once a specific area of ​​the (workgroup local) storage device has been allocated for use by a specific workgroup, the corresponding workgroup identifier of that workgroup is then appropriately stored in association with that area of ​​the (workgroup local) storage device.

[0143] Any incoming memory access from an execution thread of a workgroup will also have a corresponding identifier that identifies the workgroup they are involved in, and these identifiers can therefore be compared with identifiers for the corresponding area storage of the (workgroup local) storage device to see whether the memory access request should be permitted (or not permitted).

[0144] Identifiers can be stored per workgroup, where each distinct workgroup can (and does) be associated with a corresponding workgroup identifier, and comparisons / checks are performed based on this. Instead of using a per-workgroup identifier, per-trust-domain identity checks can also be performed, and this is done in the implementation scheme. For example, the applicant recognizes that when workgroups reside in different trust domains, it may only be necessary to block access between workgroups. This check can then work as described above, but using the corresponding per-trust-domain identifier (rather than the per-workgroup identifier) ​​to perform the check.

[0145] Therefore, in the implementation, determining whether a corresponding region of the storage device for which an execution thread is requesting access has already been allocated for use by a work item group including the execution thread includes comparing an identifier associated with the work item group for which the request is being made with a corresponding identifier stored in association with the corresponding region of the storage device, the corresponding identifier identifying the work item group for which the corresponding region of the storage device has already been allocated. As mentioned above, the identifier can be a per-workgroup identifier or a per-trust-domain identifier. In either case, when the compared identifiers do not match, this means the request is “out of bounds” and should therefore (and indeed will) be blocked.

[0146] Various other examples could be used to implement memory region access “license check” operations.

[0147] As mentioned above, if a request passes through such a memory region access "permission check" operation, the memory access request is only permitted to proceed further along the memory access path to the (workgroup local) storage device. Conversely, if the memory region access "permission check" operation is not passed (regardless of the form of the check), the memory region access "permission check" circuitry prevents the memory access request from proceeding further along the memory access path to the (workgroup local) storage device (i.e., prevents "out-of-bounds" access to the corresponding region of the storage device).

[0148] In the absence of a memory region access "permission check" operation, the memory region access "permission check" circuitry should then, and indeed does, return an appropriate response in one implementation. For example, in some implementations, the memory region access "permission check" circuitry may report an "out-of-bounds" error and, for example, return an appropriate error message to the host processor indicating the illegal memory access attempt. This can then terminate the process. Therefore, in other implementations, instead of returning an error message, the memory region access "permission check" circuitry may be configured to return another value (e.g., a suitable random or default value) that allows the process to continue (but the "out-of-bounds" memory access does not return any meaningful value) (in which case the "out-of-bounds" error can still be flagged, for example, for diagnostic procedures).

[0149] In this respect, a variety of options will be possible.

[0150] Based on the specific requirements of the technology described herein, a memory region access "license check" operation can be performed at any suitable and desired location within the graphics processor / system.

[0151] In the implementation, a memory region access "license check" operation is performed whenever there is a memory access to the (workgroup local) storage device.

[0152] In one implementation, the memory access is performed regardless of whether it is for the execution thread of the workgroup currently being executed by the programmable execution unit or for another requester (e.g., in cases where the storage device used for the "workgroup local storage device" includes storage devices that can be used for other purposes besides being intended to be used as the "workgroup local storage device" (such as those used by other processes executable by the graphics processor / system, which is the case in some implementations)).

[0153] Correspondingly, a memory region access “license check” circuit should be provided for each possible memory access path to the (workgroup local) storage device (so that whenever there is a memory access to the (workgroup local) storage device, a memory region access “license check” operation (in one embodiment, hardware-based) is performed and the check cannot be bypassed or avoided).

[0154] In this regard, it should be understood that a graphics processor / system may include a single memory region access "license check" circuit that is operable and configured to control all possible access to the (workgroup local) storage device, or multiple separate memory region access "license check" circuits may exist, each associated with a corresponding separate memory access path to the (workgroup local) storage device. Various arrangements are possible in this regard.

[0155] One or more memory region access "license check" circuits that control memory access to the (workgroup local) storage device and are operable to perform memory region "license access" checks according to the techniques described herein can be any suitable and desired circuitry configured to perform and execute such operations, and can be arranged relative to the storage device in any suitable and desired configuration and location. It should, and in one embodiment, be (at least logically) located between the programmable processing unit and the (workgroup local) storage device. In one embodiment, it is located at an appropriate point along the "access" path between the programmable processing unit (its instruction execution circuitry (execution engine)) and the (workgroup local) storage device.

[0156] However, various arrangements were envisioned for this purpose.

[0157] For example, in some embodiments, the memory region access “license check” circuitry is associated with and is part of the programmable processing unit, and thus in one embodiment is operable and configured to perform a memory region “license access” check operation on a memory access request of an execution thread of a workgroup being executed by the programmable processing unit before the memory access request is passed to the storage device.

[0158] In one implementation, the processing circuitry is part of and / or includes the circuitry that controls access to the (local) storage device (i.e., such that any access request to the (local) storage device from the programmable processing unit (of the instruction execution circuitry) will be passed through and controlled by the (local) storage device access circuitry, which is at least part of the processing circuitry).

[0159] This means that if a memory access request fails the “permitted access” check operation for such a memory region, an appropriate result (e.g., an error message, as described above) can be returned without having to pass the memory access to the entire storage device (memory) unit that provides the workgroup’s local storage.

[0160] However, this or a memory region access “license check” circuitry may also be associated with the entire storage device (memory) unit that provides local storage for the workgroup, and is part of it in one embodiment. For example, in one embodiment, the storage device includes such processing circuitry in addition to the appropriate storage elements (e.g., memory banks).

[0161] In this respect, various examples will be possible.

[0162] For example, in one embodiment, the storage device is configured as a plurality of independently accessible storage units, each storage unit having a corresponding (separate) accessor circuitry, and a corresponding (separate) memory region access "license check" circuitry may be associated with each of the plurality of independently accessible storage units and is part of it in the embodiment (e.g., by being associated with and part of the corresponding accessor circuitry for the corresponding storage unit of the storage device).

[0163] As mentioned above, in some implementations, the storage device for “workgroup local storage device” includes storage devices that can be used for other purposes besides being intended to be used as “workgroup local storage device” (such as those used by other processes executable by the graphics processor / system) (this is the case in some implementations), and in this case, (also) a memory region access “license check” circuit should be provided, which is operable and configured to perform a memory region access “license check” operation on requests from such “other” requesters.

[0164] For example, in cases where the (workgroup local) storage device is also shared with one or more other units (or one or more processes) capable of using the storage device (besides the workgroup local storage device used by the workgroup being executed by the programmable processing unit), in an embodiment, the system (e.g., graphics processor / system) includes appropriate arbitration circuitry and processes to arbitrate between access to the storage device in relation to its use as a workgroup local storage device (e.g., via corresponding accessor circuitry) and access requests to the storage device from other "requesters". In cases where the storage device comprises multiple memory banks, in one embodiment, the arbitration is performed and provided on a bank-by-bank basis.

[0165] (The arbitrator (arbitration process) can be configured to operate according to expectations, for example, to always prioritize memory access requests from "another" requester, or to always prioritize requests related to the workgroup. Similarly, there may be multiple other requesters capable of accessing the storage device, each with an appropriate arbitration (priority) strategy in its place.)

[0166] Therefore, in some implementations, the corresponding (separate) memory region access "license check" circuitry may be associated with, and in one implementation, as part of, a corresponding arbitration circuitry that performs arbitration against the corresponding memory bank of the storage device. This means that the same memory region access "license check" circuitry can perform memory region access "license check" operations for memory access requests from the execution thread of the workgroup being executed by the programmable processing unit and from any "other" requester, wherein the memory region access "license check" is performed within the (workgroup-local) storage device, thus eliminating the need for separate circuitry to do so.

[0167] However, other arrangements are also possible. For example, in one implementation, a separate and dedicated memory region access "license check" circuit may be provided for the (or each) "other" requester located at a suitable point along the "access" path between the "other" requester and the (workgroup local) storage device. For example, it may be associated with the "other" requester and, in one implementation, located within it. In this case, one (or more) memory region access "circuitary" circuits that perform memory region access "license checks" on requests from the execution thread of the workgroup are provided separately to the circuitry controlling access to the "other" requester and may be provided in any suitable manner, such as as described above.

[0168] In this respect, various arrangements will be possible.

[0169] The techniques described in this article can generally be applied to any suitable graphics processing system.

[0170] The graphics processing system may also include a host processor that performs data or graphics processing that may require the graphics processor and accordingly (e.g., via a driver for the graphics processor) instructs the graphics processor. The system may also include suitable storage devices (e.g., memory), caches, etc.

[0171] The graphics processing system and / or graphics processor may also include one or more memory and / or memory devices for storing data and / or storing software for performing the processes described herein, and / or communicate with said one or more memory and / or memory devices. The graphics processing system and / or graphics processor may also communicate with a host microprocessor and / or a display for displaying images based on the generated data.

[0172] A graphics processor may include (implement) any one or more of the processing stages that a graphics processor (processing pipeline) typically includes. Thus, for example, a graphics processor may include a primitive setup stage, a rasterizer, and / or a renderer (in one embodiment, in the form of a fragment shader).

[0173] A graphics processor (processing pipeline) may include one or more programmable shading stages, such as one or more or all of the following: vertex shading stage, shell shader, tessellation stage (e.g., where tessellation is performed by executing a shader program), domain (evaluation) shading stage (shader), geometry shading stage (shader), and fragment shader.

[0174] The graphics processing unit (processing pipeline) may also include any other suitable and desired processing stages that a graphics processing pipeline may include, such as a depth (or depth and stencil) tester, a mixer, one or more tile buffers, a write unit, etc.

[0175] The techniques described herein can be used in and with any suitable and desired graphics processing system and processor. In one implementation, the graphics processor (processing pipeline) is a tile-based graphics processor (processing pipeline).

[0176] The techniques described herein can be used with any form of output that a graphics processor can generate. In one implementation, it is used when a graphics processor is generating an image for display, but it can also be used with any other form of graphics processing output, such as a graphics texture that the graphics processor can render to a texture operation (e.g., post-processing) as desired. It can also be used when a graphics processor is generating other (e.g., non-image or non-graphic) outputs.

[0177] In one implementation, the various functions of the techniques described herein are executed on a single data or graphics processing platform that generates and outputs the required data, such as image data being processed and written to a frame buffer for a display device.

[0178] The techniques described herein can be implemented in any suitable system, such as a microprocessor-based system capable of proper operation. In some implementations, the techniques described herein are implemented in computer- and / or microprocessor-based systems.

[0179] The various functions of the technology described herein can be performed in any desired and suitable manner. For example, the functions of the technology described herein can be implemented in hardware or software as needed. Thus, for example, the various functional elements, stages, units, and “devices” of the technology described herein may include one or more suitable processors, one or more controllers, functional units, circuits, processing logic, microprocessor arrangements, etc., capable of operating to perform various functions, such as appropriate dedicated hardware elements (processing circuits) and / or programmable hardware elements (processing circuits) that can be programmed to operate in a desired manner.

[0180] It should also be noted that the various functions of the technology described herein can be copied and / or executed in parallel on a given processor. Similarly, various processing stages can share processing circuitry / circuits, etc., if needed.

[0181] Furthermore, any one or more processing stages or units of the technology described herein may be embodied as processing stage or unit circuits, for example, in the form of one or more fixed-function units (hardware) (processing circuits), and / or in the form of programmable processing circuits that can be programmed to perform desired operations. Similarly, any one or more of the processing stages or units and processing stage or unit circuits of the technology described herein may be provided as independent circuit elements to other processing stages or units or processing stage or unit circuits, and / or any one or more or all of the processing stages or units and processing stage or unit circuits may be formed at least partially by shared processing circuitry.

[0182] Those skilled in the art should also understand that all embodiments of the technology described herein may include any one or more or all of the features described herein, as appropriate.

[0183] The methods described herein can be implemented at least in part using software (e.g., computer programs). Therefore, further embodiments of the techniques described herein include: computer software specifically adapted to perform the methods described herein when installed on a data processor; computer program elements including computer software code portions for performing the methods described herein when the program elements are run on the data processor; and a computer program adapted to perform all steps of one or more methods described herein when the program is run on a data processing system. The data processing system may be a microprocessor, a programmable FPGA (Field-Programmable Gate Array), etc.

[0184] The techniques described herein also extend to computer software carriers that, when used to operate a graphics processor, renderer, or other system including a data processor, cause said processor, renderer, or system to perform the steps of the methods described herein in conjunction with said data processor. Such computer software carriers can be physical storage media, such as ROM chips, CD-ROMs, RAM, flash memory, or disks, or they can be signals, such as electronic signals transmitted through wires, optical signals, or radio signals, such as signals to satellites.

[0185] It should also be understood that not all steps of the methods described herein need to be performed by computer software; therefore, other embodiments of the techniques described herein include computer software and such software installed on a computer software carrier for performing at least one step of the methods described herein.

[0186] Therefore, the techniques described herein may suitably be embodied as a computer program product used with a computer system. Such embodiments may include a series of computer-readable instructions fixed on a tangible, non-transitory medium, such as a computer-readable medium, for example, a disk, CD-ROM, ROM, RAM, flash memory, or hard disk. It may also include a series of computer-readable instructions that can be invisibly transmitted to a computer system via a modem or other interface device, through a tangible medium (including, but not limited to, optical communication lines or analog communication lines), or using wireless technologies (including, but not limited to, microwave, infrared, or other transmission technologies). This series of computer-readable instructions embodies all or part of the functionality previously described herein.

[0187] Those skilled in the art will understand that such computer-readable instructions can be written in a variety of programming languages ​​to be used with many computer architectures or operating systems. Furthermore, such instructions can be stored using any current or future memory technology (including, but not limited to, semiconductor, magnetic, or optical technologies), or transmitted using any current or future communication technology (including, but not limited to, optical, infrared, or microwave technologies). It is conceivable that such computer program products can be distributed as removable media with accompanying printed or electronic documentation (e.g., shrink-wrapping software), pre-loaded with a computer system on, for example, a system ROM or a fixed disk, or distributed via a network (e.g., the Internet or the World Wide Web) from a server or electronic bulletin board.

[0188] Figure 1 An exemplary system-on-chip (SoC) graphics processing system 8 is shown, which includes a host processor in the form of a central processing unit (CPU) 1, a graphics processing unit (GPU) 2, a display processor 3, and a memory controller 5.

[0189] like Figure 1 As shown, these units communicate via interconnect 4 and have access to off-chip memory 6. In this system, graphics processor 2 renders frames (images) to be displayed, and then display processor 3 provides these frames to display panel 7 for display.

[0190] In the use of this system, an application 13, such as a game, running on the host processor (CPU) 1, will, for example, need to display frames on the display panel 7. To do this, the application will submit appropriate commands and data to the driver 11 for the graphics processor 2 running on the CPU 1. The driver 11 will then generate appropriate commands and data to cause the graphics processor 2 to render appropriate frames for display and store these frames in appropriate frame buffers, such as in main memory 6. The display processor 3 will then read these frames into the buffer for display, and then read these frames from the buffer and display them on the display panel 7 of the monitor.

[0191] Figure 2 The relevant elements and components of the graphics processor (GPU) 60 according to an embodiment of the present invention are schematically shown.

[0192] like Figure 2 As shown, GPU 60 includes one or more programmable processing units (shader (processing) cores) 61, 62, a memory management unit 63, and a secondary cache 64, which is operable to communicate with an off-chip memory system 68 (e.g., via appropriate interconnects and a (dynamic) memory controller).

[0193] Figure 2 The configuration of a shader core 61 is shown schematically, but as those skilled in the art will understand, any other shader cores of the graphics processor 60 will be configured in a corresponding manner.

[0194] (Graphics Processing Unit (GPU) shader cores 61 and 62 are programmable processing units (circuits) that perform processing operations by running small programs for each "item" in the output to be generated (such as a rendering target, e.g., a frame). In this respect, an "item" can be, for example, a vertex, one or more sampled locations, a computed shader "work item," etc. The shader core will process each "item" through one or more execution threads, which will execute the instructions of the shader program considered for the "item" under consideration. Typically, there will be multiple execution threads, each executing simultaneously (in parallel).)

[0195] Figure 2The main components of a graphics processor 60 related to the operation of an embodiment of the present invention are shown. As those skilled in the art will understand, the graphics processor 60 may have... Figure 2 Other components not listed herein. It should also be noted here that... Figure 2 This is merely illustrative, and even if the functional units shown are in... Figure 2 While schematically shown as separate units, they may also share important hardware circuitry. It should also be understood that, unless otherwise indicated, as... Figure 2 Each of the components and units of the graphics processor shown can be implemented as desired, and will accordingly include, for example, appropriate circuitry (processing logic) for performing necessary operations and functions.

[0196] like Figure 2 As shown, each shader core of the graphics processor 60 includes a suitable instruction execution unit (execution engine) 65, which is operable to execute shader programs for execution threads to perform processing operations.

[0197] The shader core 61 also includes an instruction cache 66 that stores instructions to be executed by the instruction execution unit 65 to perform processing operations. The instructions to be executed are fetched from the memory system 68 via interconnect 69 and a miniature TLB (translation back buffer) 70.

[0198] The shader core 61 also includes a suitable load / store unit 76 in communication with the instruction execution unit 65. This load / store unit is operable to load, for example, data into a suitable cache for processing by the instruction execution unit 65, and to write data back to the memory system 68 (for loading and storing data for the program executed in the instruction execution unit). Similarly, such data is acquired / stored by the load / store unit 76 via interconnect 69 and a miniature TLB 70.

[0199] In order to perform graphics processing operations, the instruction execution unit 65 will execute the graphics shader program (instruction sequence) for the corresponding execution thread.

[0200] Therefore, as Figure 2 As shown, the shader core 61 also includes a bundle manager 72, which is operable to generate execution threads for execution by the instruction execution unit 65, publish such threads to the instruction execution unit 65, and control the scheduling of threads on / to the instruction unit 65 for execution.

[0201] Embodiments of the present invention particularly relate to the operation of a graphics processor (and in particular, the shader cores of the graphics processor) when dealing with so-called “workgroups” (i.e., a collection of execution threads (corresponding to corresponding work items) that are processed as a whole and considered as a “group” and are therefore all guaranteed to exist simultaneously (having the same lifetime) and capable of communicating and synchronizing with each other) (e.g., when performing computational shading). Therefore, the bundle manager 72 is correspondingly operable to generate corresponding workgroups of execution threads, and to publish and schedule such workgroups of threads on and to the instruction execution unit 65.

[0202] To facilitate such workgroup operations, and especially to facilitate data sharing between threads within a workgroup, such as Figure 2 As shown, the shader core 61 also includes a shared memory unit (SMU) 74, which communicates with the instruction execution unit (execution engine) 65 and the bundle manager 72.

[0203] The shared memory unit 74 is operable to provide a "workgroup local storage device" for execution threads in a corresponding workgroup. When the workgroup is being executed (when the workgroup exists), the execution threads can read from and write to the "workgroup local storage device" to allow data sharing between threads within the workgroup.

[0204] Specifically, a corresponding memory region within the shared memory unit can be allocated to each workgroup for use as a "workgroup local storage device" while the workgroup is in operation. When a workgroup reaches the end of its lifetime, the "local storage device" memory region in the shared memory unit 74 is deallocated, making it available for use by another workgroup.

[0205] In the embodiments of the present invention, such as Figure 2 As shown, the shared memory unit providing the workgroup local storage is local to the shader core 61 and is on the chip along with the shader core. Of course, other arrangements of this configuration are also possible.

[0206] (The allocation of the area of ​​shared memory unit 74 to the corresponding workgroup can be performed in any suitable and desired manner, such as in the normal manner for the graphics processor and graphics processing system under consideration.)

[0207] Figure 3 The shared memory unit 74 of the workgroup local storage device is shown in more detail.

[0208] like Figure 3 As shown, it is assumed that the local storage device of the workgroup shares memory unit 74, which includes multiple memory (SRAM) banks 31. Figure 3Four memory modules 31 are shown, but other numbers and arrangements of memory modules are of course possible.

[0209] like Figure 3 As shown (and as mentioned above regarding) Figure 2 (As discussed), the workgroup local storage device shared memory unit 74 is operable to receive commands from the bundle manager 72, and also from the execution engine 65, as well as read and write operations and atomic operations.

[0210] like Figure 3 As shown, the workgroup local storage device shared memory unit 74 also includes a set of memory bank access control units (circuits) 32, one for each memory bank 31. These access unit units (circuits) 32 control access to the memory bank 31, as will be discussed in more detail below.

[0211] like Figure 3 As shown, according to the technology described herein, execution engine 65 includes memory region “access permission check” circuitry 65A. As discussed above, this circuitry is operable and configured to perform appropriate “boundary checks” for any memory access to the shared memory unit 74 of the workgroup being executed by execution engine 65 for the execution threads of the workgroup.

[0212] The memory region “access permission check” circuit 65A is configured to perform a “boundary check” in any suitable and desired manner.

[0213] For example, based on a primary example (corresponding to the "second primary example" mentioned above), perform a "boundary check" based on the "trust domain" identifier. This will be about Figure 4 , Figure 5 and Figure 6 To describe in more detail.

[0214] Figure 4 The operation of the bundle manager 72 is shown when a new computation run command is received to process a new workgroup.

[0215] like Figure 4 As shown, upon receiving a new computation run command (step 401), the bundle manager 72 then allocates a corresponding area of ​​the workgroup local storage device shared memory unit 74 for use by the workgroup associated with the computation run command (step 402). This allocation can be performed in any suitable and desirable manner, such as in the normal manner for such allocations.

[0216] Then, at this point, and in one implementation, the allocated area of ​​the shared memory unit 74 of the workgroup local storage device should indeed be cleared (step 403) to ensure the removal of any data from the previous workgroup. This clearing operation can be performed in various suitable ways as desired. For example, in some implementations, a dedicated clearing operation can be automatically triggered by the step of allocating the corresponding area of ​​the shared memory unit 74 of the workgroup local storage device for use by the new workgroup (i.e., by step 402), for example, in response to a suitable “clear” command issued by the bundle manager 72. However, various other examples are also possible.

[0217] Then, trust domain identifiers that identify the new workgroup are assigned to all areas of the workgroup local storage device shared memory unit 74 that have been allocated for use by the workgroup (step 404). These trust domain identifiers are then appropriately stored in association with the corresponding areas of the workgroup local storage device shared memory unit 74 (e.g., as shown in the image). Figure 6 (As shown).

[0218] Then, Figure 5 The corresponding "boundary check" operation is shown, that is, in this embodiment, the corresponding "boundary check" operation performed by the memory region "access permission check" circuit 65A for incoming memory access.

[0219] like Figure 5 As shown, when the execution thread of the workgroup being processed by the execution engine 65 requests access to the workgroup local storage device shared memory unit 74 (step 501), it is checked whether the trust domain identifier used for memory access matches the trust domain identifier for the region storage of the workgroup local storage device shared memory unit 74 that is requesting access (step 502).

[0220] If the trust domain identifier does not match (step 502 - No), the memory region “access permission check” circuit 65A then reports an “out of bounds” error (step 503) and prevents the memory access request from reaching the workgroup local storage device shared memory cell 74.

[0221] On the other hand, if the trust domain identifier matches (step 502 - yes), the memory region “access permission check” circuit 65A then permits the memory access request to proceed further to the workgroup local storage device shared memory unit 74 (step 504).

[0222] Then, Figure 6 The arrangement of the shared memory unit 74 of the workgroup local storage device in this example is shown. Figure 6As shown, each SRAM bank 32 includes multiple entries (locations) that can (and have been) been assigned to workgroups in different trust domains. Associated with each entry (location) is a corresponding trust domain identifier, which can be used to perform "boundary checks" as described above.

[0223] This example has the benefit of being able to allocate non-contiguous memory blocks to workgroups. However, it does require some per-block storage to do so.

[0224] As expected, "boundary checks" can be performed in other ways.

[0225] For example, in another primary example (corresponding to the "first primary example" mentioned above), range-based boundary checks are performed. This will be about... Figure 7 , Figure 8 and Figure 9 To describe in more detail.

[0226] Figure 7 The corresponding operation of the bundle manager 72 according to this example is shown.

[0227] like Figure 7 As shown, when a new compute run command is received (step 701), the bundle manager 72 may then generate one or more (typically multiple) workgroups to be executed for the compute run command (and thus it is known that all workgroups in these workgroups come from the same trust domain).

[0228] Then, the bundle manager 72 allocates a corresponding area of ​​the workgroup local storage device shared memory unit 74 for use by each workgroup in the workgroup generated by the computation run command (step 702), and then, at this point, and in one embodiment, the allocated area of ​​the workgroup local storage device shared memory unit 74 should indeed be cleared (step 703), as described above.

[0229] At this point, the allocation base address and size of the full area of ​​the local storage device that has been allocated for all workgroups (and therefore from the same trust domain) in the workgroup generated by the running computation command are then stored as per-trust domain state associated with all execution threads (bundles) of the workgroup associated with the running command (step 704).

[0230] Then, Figure 8 The corresponding "boundary check" operation is shown, that is, in this embodiment, the corresponding "boundary check" operation performed by the memory region "access permission check" circuit 65A for incoming memory access.

[0231] like Figure 8As shown, when an execution thread of the workgroup being processed by the execution engine 65 requests access to the shared memory unit 74 of the workgroup local storage device (step 801), it is checked whether the memory access is attempting to access memory outside the allowed address range determined by the base address and size stored in the per-trust domain state of the execution thread (bundle) that is initiating the memory access (step 802).

[0232] If the request is outside the allowed address range (step 802 - Yes), the memory region “access permission check” circuit 65A then reports an “out of bounds” error (step 803) and prevents the memory access request from reaching the workgroup local storage device shared memory cell 74.

[0233] On the other hand, as long as the request is within the allowed address range (step 802 - No), the memory region "access permission check" circuit 65A then proceeds to the workgroup local storage device shared memory unit 74 to grant the memory access request (step 804).

[0234] Then, Figure 9 The arrangement of the shared memory unit 74 of the workgroup local storage device in this second main example is shown. For example... Figure 9 As shown, each SRAM bank 32 includes multiple entries (locations) that can (and have been) been allocated for workgroups in different trust domains. A separate allocation table 901 is provided to store the corresponding base addresses and size values ​​for the different trust domains, which can be used to perform "boundary checks" as described above.

[0235] This example has the advantage of avoiding per-block storage (at least compared to the example described above), because instead, only per-trust-domain storage is required. This then requires fewer storage bits, but at the cost of not being able to allocate non-contiguous memory blocks.

[0236] Various other examples are also possible.

[0237] For example, although the above text is about Figures 4 to 6 and Figures 7 to 9 The example described performs a memory region “access permission check” based on each trust domain, but it should be understood that this can also be done on a per-workgroup basis (i.e., by storing an appropriate “workgroup” identifier or storing an address range for each workgroup) (and in this case, a given workgroup will only be permitted access to a specific area of ​​the storage device that has been allocated for its use).

[0238] exist Figure 3As described above, the memory region “access permission check” circuitry 65A is provided within the execution engine 65. However, such memory region “access permission check” circuitry can be provided at any suitable location within the graphics processor, provided that it can perform the appropriate “boundary check” required for any access to the shared memory unit 74 of the workgroup local storage device (and provided that the boundary being checked does not originate from an untrusted source, such as an instruction stream).

[0239] For example, Figure 10 Another example is shown, in which a memory region “access permission check” circuit 74A is provided within a shared memory cell 74 of a workgroup local storage device.

[0240] Figure 11 Another example is shown, wherein each of the respective memory access control units (circuits) 32 in the respective memory access control unit (circuit) includes a respective memory region “access permission check” circuit 32A, such that a respective memory region “access permission check” circuit 32A is provided for each memory bank 31.

[0241] The above description Figure 3 , Figure 10 and Figure 11 Various arrangements are shown, in which the workgroup local storage shared memory unit 74 is dedicated to and can be used by the workgroup local storage of the workgroup executing on the execution engine 65.

[0242] Figure 12 Alternative arrangements and implementations are shown, in which the workgroup local storage device shares memory unit 90 with another unit (requester) 91 that can access the memory bank of shared memory unit 90.

[0243] Therefore, in this case, the shared memory unit 90 also includes a set of arbitrators (arbitration circuits) 92, which are operable to arbitrate memory access requests between another requester 91 and the workgroup local storage device accessor unit 32.

[0244] In this arrangement, the arbitrator 92 can be configured to operate as desired, for example, to always prioritize memory access requests from "another" requester 91, or to always prioritize requests related to the workgroup. Similarly, multiple other requesters capable of accessing memory may exist, each with an appropriate arbitration (priority) strategy in its place.

[0245] In this arrangement, upon receiving a higher priority request from another requester 91, memory access associated with the workgroup will be appropriately suspended until the other request has been served and can then be resumed (and vice versa).

[0246] In this scenario, if desired, a "boundary check" should also be performed on memory accesses from another requester 91 to determine whether an access is being made to a region of shared memory cells that have already been allocated to a specific workgroup (and to prevent any access from another requester to regions of memory cells already allocated to the workgroup). This will prevent other memory accesses from other requesters from interfering with the workgroup's local storage region.

[0247] Such memory region boundary checks can be implemented in any suitable and desirable manner, such as those described above.

[0248] For example, such as Figure 12 As shown, each arbitrator (arbitration circuit) in the arbitrator (arbitration circuit) 92 may include a corresponding memory region “access permission check” circuit 92A, wherein the corresponding memory region “access permission check” circuit 92A is thus operable to perform a “boundary check” for both requests from another requester 91 and requests from the workgroup local storage device accessor unit 32.

[0249] However, other arrangements are also possible. For example, such as Figure 13 , Figure 14 and Figure 15 As shown, the "other" requester 91 itself may include its own corresponding memory region "access permission check" circuitry 91A, which performs a "boundary check" for any request from the other requester 91. In this case, one(s) memory region "access permission check" circuitry performing a "boundary check" for any request from the execution engine 65 may be located in any suitable location, such as within the execution engine 65, within the workgroup local storage shared memory unit 74, within the memory access control unit (circuit) 32, etc., as described above with respect to the previous figures.

[0250] As can be seen from the above, the technology described herein, at least in its implementation, can provide improved operation and implementation when a workgroup using a workgroup local storage device is being executed by a programmable processing unit of a graphics processor.

[0251] The specific embodiments described above are presented for illustrative and descriptive purposes only. They are not intended to be exhaustive or to limit the technology described herein to the precise forms disclosed. Many modifications and variations are possible in accordance with the teachings above. The described embodiments were chosen to best explain the principles of the technology described herein and its practical application, thereby enabling others skilled in the art to best utilize the technology described herein in various embodiments and with various modifications suitable for the particular intended use. The scope of the invention is intended to be defined by the appended claims.

Claims

1. A graphics processing system, the graphics processing system comprising: A programmable processing unit, operable to execute a processing program for executing threads, the execution threads corresponding to work items to be processed by the graphics processing system; A storage device, wherein a corresponding area of ​​the storage device can be allocated for temporary use by a corresponding execution thread group, the corresponding execution thread group corresponding to a group of work items being executed by the programmable processing unit while the execution thread group is being executed. The graphics processing system further includes one or more memory region access permission checking circuits that control memory access to the storage device, the one or more memory region access permission checking circuits being configured to: When a request is made to access a corresponding area of ​​the storage device for an execution thread of a work item group being executed by the programmable processing circuit: Determine whether the execution thread requesting access to the corresponding area of ​​the storage device is permitted to access the area of ​​the storage device; as well as When it is determined that the execution thread is not permitted to access the corresponding area of ​​the storage device, the execution thread is prevented from accessing the area of ​​the storage device.

2. The system of claim 1, wherein different work item groups can reside in different trust domains, and wherein determining whether the execution thread requesting access to the corresponding region of the storage device is permitted to access the region of the storage device comprises: Determine whether the corresponding area of ​​the storage device that the execution thread is requesting access to has already been allocated for use by the work group that includes the execution thread, or for use by another work group that is in the same trust domain as the work group that includes the execution thread; and wherein if it is determined that the execution thread making the request is not the execution thread of the work group for which the corresponding area of ​​the storage device has been allocated or the execution thread of another work group in the same trust domain, access to the corresponding area of ​​the storage device is blocked.

3. The system of claim 2, wherein determining whether a corresponding region of the storage device that the execution thread is requesting access to has been allocated for use by the work item group including the execution thread or for use by another work item group within the same trust domain as the work item group including the execution thread comprises: The identifier associated with the work item group for which the request is being made is compared with a corresponding identifier stored in relation to the corresponding region of the storage device for which the execution thread is requesting access. The corresponding identifier identifies the work item group or trust domain for which the corresponding region of the storage device has been allocated.

4. The system of claim 2, wherein determining whether a corresponding region of the storage device that the execution thread is requesting access to has been allocated for use by the work item group including the execution thread or for use by another work item group within the same trust domain as the work item group including the execution thread comprises: The memory address that is making the request is compared with a memory address range that identifies the corresponding region of the storage device that has been assigned to the work item group that is making the request or that includes the trust domain of the work item group.

5. The system according to any one of the preceding claims, wherein the one or more memory region access permission checking circuits include a memory region access permission checking circuit associated with the programmable execution unit.

6. The system according to any one of the preceding claims, wherein the one or more memory region access permission checking circuits are associated with the storage device.

7. The system of claim 6, wherein the storage device is configured as a plurality of independently accessible storage units, and wherein a corresponding memory region access permission checking circuit is associated with each independently accessible storage unit of the storage device.

8. The system according to any one of the preceding claims, wherein the storage device is capable of being used for other purposes and storage, wherein a corresponding storage area is capable of being allocated for temporary use by a corresponding execution thread group, the corresponding execution thread group corresponding to a work item group being executed by the programmable processing unit while the execution thread group is being executed, and wherein the one or more memory area access permission checking circuits are further configured to control access to the storage device for requesters of execution threads that are not being executed by the programmable processing unit.

9. The system of claim 8, wherein the system further comprises: One or more arbitration circuits are configured to receive both storage device access requests related to a workgroup storage area and access requests from other requesters, and to arbitrate between the requests, wherein a corresponding memory area access permission check circuit is associated with each of the one or more arbitration circuits.

10. The system according to any one of the preceding claims, wherein the storage device is local to the programmable processing unit of the graphics processor and is on-chip together with the programmable processing unit of the graphics processor.

11. A graphics processor, the graphics processor comprising: A programmable processing unit, operable to execute a processing program for executing threads, the execution threads corresponding to work items to be processed by the graphics processor; The graphics processor further includes one or more memory region access permission checking circuits for controlling memory access to a storage device, wherein a corresponding region of the storage device can be allocated for temporary use by a corresponding execution thread group, the corresponding execution thread group corresponding to a group of work items being executed by the programmable processing unit while the execution thread group is being executed, and the one or more memory region access permission checking circuits are configured to: When a request is made to access a corresponding area of ​​the storage device for an execution thread of a work item group being executed by the programmable processing circuit: Determine whether the execution thread requesting access to the corresponding area of ​​the storage device is permitted to access the area of ​​the storage device; as well as When it is determined that the execution thread is not permitted to access the corresponding area of ​​the storage device, the execution thread is prevented from accessing the area of ​​the storage device.

12. A method for operating a graphics processing system, the graphics processing system comprising: A programmable processing unit, operable to execute a processing program for executing threads, the execution threads corresponding to work items to be processed by the graphics processing system; A storage device, wherein a corresponding area of ​​the storage device can be allocated for temporary use by a corresponding execution thread group, the corresponding execution thread group corresponding to a group of work items being executed by the programmable processing unit while the execution thread group is being executed; and One or more memory region access permission checking circuits, said one or more memory region access permission checking circuits controlling memory access to the memory device. The method includes: When a request is made to access a corresponding area of ​​the storage device for an execution thread of a work item group being executed by the programmable processing circuit: The one or more memory region access permission check circuits: Determine whether the execution thread requesting access to the corresponding area of ​​the storage device is permitted to access the area of ​​the storage device; as well as When it is determined that the execution thread is not permitted to access the corresponding area of ​​the storage device, the execution thread is prevented from accessing the area of ​​the storage device.

13. The method of claim 12, wherein different work item groups can reside in different trust domains, and wherein determining whether the execution thread requesting access to the corresponding region of the storage device is permitted to access the region of the storage device comprises: Determine whether the corresponding area of ​​the storage device that the execution thread is requesting access to has already been allocated for use by the work group that includes the execution thread, or for use by another work group that is in the same trust domain as the work group that includes the execution thread; and wherein the method includes: blocking access to the corresponding area of ​​the storage device when it is determined that the execution thread making the request is not the execution thread of the work group that has already allocated the corresponding area of ​​the storage device for use, or the execution thread of another work group in the same trust domain.

14. The method of claim 13, wherein determining whether a corresponding region of the storage device that the execution thread is requesting access to has been allocated for use by the work item group including the execution thread or for use by another work item group within the same trust domain as the work item group including the execution thread comprises: The identifier associated with the work item group for which the request is being made is compared with a corresponding identifier stored in association with the corresponding region of the storage device, the corresponding identifier identifying the work item group or trust domain for which the corresponding region of the storage device has been allocated.

15. The method of claim 13, wherein determining whether a corresponding region of the storage device that the execution thread is requesting access to has been allocated for use by the work item group including the execution thread or for use by another work item group within the same trust domain as the work item group including the execution thread comprises: The memory address that is making the request is compared with a memory address range that identifies the corresponding area of ​​the storage device that has been assigned to the workgroup making the request or the trust domain that includes the workgroup.

16. The method of any one of claims 12 to 15, wherein the one or more memory region access permission checking circuits include a memory region access permission checking circuit associated with the programmable execution unit.

17. The method of any one of claims 12 to 16, wherein the one or more memory region access permission checking circuits are associated with the storage device.

18. The method of claim 17, wherein the storage device is configured as a plurality of independently accessible storage units, and wherein a corresponding memory region access permission checking circuit is associated with each independently accessible storage unit of the storage device.

19. The method of any one of claims 12 to 18, wherein the storage device is capable of being used for other purposes and for storage, wherein a corresponding storage region is capable of being allocated for temporary use by a corresponding execution thread group, the corresponding execution thread group corresponding to a work item group being executed by the programmable processing unit while the execution thread group is being executed, and wherein the one or more memory region access permission checking circuits are further configured to control access to the storage device for requesters of execution threads that are not being executed by the programmable processing unit.

20. The method of claim 19, wherein the system further comprises: One or more arbitration circuits are configured to receive both storage device access requests related to a workgroup storage area and access requests from other requesters, and to arbitrate between the requests, wherein a corresponding memory area access permission check circuit is associated with each of the one or more arbitration circuits.

21. The method according to any one of claims 12 to 20, wherein the storage device is local to the programmable processing unit of the graphics processor and is on-chip together with the programmable processing unit of the graphics processor.

22. A method of operating a graphics processor, the graphics processor comprising: A programmable processing unit, operable to execute a processing program for executing threads, the execution threads corresponding to work items to be processed by the graphics processor; and One or more memory region access permission checking circuits control memory access to a storage device, wherein corresponding regions of the storage device can be allocated for temporary use by corresponding execution thread groups, the corresponding execution thread groups corresponding to a group of work items being executed by the programmable processing unit while the execution thread group is being executed. The method includes: When a request is made to access a corresponding area of ​​the storage device for an execution thread of a work item group being executed by the programmable processing circuit: The one or more memory region access permission check circuits: Determine whether the execution thread requesting access to the corresponding area of ​​the storage device is permitted to access the area of ​​the storage device; as well as When it is determined that the execution thread is not permitted to access the corresponding area of ​​the storage device, the execution thread is prevented from accessing the area of ​​the storage device.

23. A computer program comprising computer software code for performing the method according to any one of claims 12 to 22 when the program is run on one or more processors.

Images