Processor device that collects performance information through command set-based replay

Abstract

The processor device includes a scheduler and a performance counter. The scheduler schedules commands of a first command set and commands of a second command set on a processor circuit. When the processor circuit processes a first operation guided by the first command set and a second operation guided by the second command set, the performance counter counts the number of times an event of interest occurs respectively. The commands of the first command set are repeatedly scheduled so that the number of times all events of interest are counted for the first operation. After the number of times all events of interest are counted for the first operation, the commands of the second command set are scheduled.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the priority benefit of Patent Application No. 10-2018-0002881 filed on January 9, 2018 in the Korean Intellectual Property Office, the entire contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] The present disclosure relates to an electronic device, and more particularly, to the operation and configuration of a processor device configured to process various operations. Background Art

[0004] In recent years, various types of electronic devices are being used. The electronic device performs its own functions according to the operation of the electronic circuits and devices included in the electronic device. For example, the electronic device may include a processor device, and various functions may be provided according to the operation of the processor device.

[0005] The processor device performs logical operations and / or arithmetic operations to process a request (e.g., from a user or from other components within the electronic device). In this way, the processor device outputs an operation result corresponding to the request. The operation result is used to operate the electronic device.

[0006] For example, processor devices can be divided into general-purpose processor devices and special-purpose (or dedicated) processor devices. General-purpose processor devices can support various general operations and can intervene in the overall operation of electronic devices. On the other hand, special-purpose processor devices can be configured to support specific types of operations. Graphics processor devices are examples of special-purpose processor devices. For example, graphics processor devices can perform operations dedicated to graphics processing by using parallel processors to quickly process large amounts of graphics data.

[0007] While an operation is being processed by a processor device, various events may occur. For example, required data may or may not be present in a cache memory (i.e., a cache hit or cache miss), or a conflict may occur between data paths through a bus. These events may affect the performance of the operation to be processed by the processor device. Summary of the invention

[0008] Example embodiments of the present disclosure may provide configurations and operations for collecting performance information from events occurring for operations of a processor device. In some example embodiments of the present disclosure, performance information may be collected through command set-based replay.

[0009] In some embodiments, the present disclosure relates to a processor device, comprising: a scheduler, configured to schedule a first command of a first command set and a second command of a second command set, so that a processor circuit processes a first operation directed by the first command set and a second operation directed by the second command set; a performance counter, configured to count the number of times an event of interest occurs when the processor circuit processes the first operation and the second operation, wherein each number corresponds to one of the events of interest; and a register, configured to store a count value corresponding to the counted number of times, wherein, when the number of events of interest is greater than the number of registers, the first operation is repeatedly processed so that the number of all events of interest is counted for the first operation, and the second operation is processed after the number of all events of interest is counted for the first operation.

[0010] In some embodiments, the present disclosure relates to a processor device, comprising: a scheduler configured to schedule a first command of a first command set and a second command of a second command set; and a performance counter configured to count the number of events of interest that occur with respect to processing a first operation directed by the first command set and a second operation directed by the second command set, wherein each number corresponds to one of the events of interest, wherein the first command in the first command set is repeatedly scheduled so that the number of all events of interest is counted for the first operation, and wherein, after the number of all events of interest is counted for the first operation, the second command in the second command set is scheduled.

[0011] In some embodiments, the present disclosure relates to a processor device comprising: a processor circuit configured to process operations directed by each of a plurality of command sets; and a performance counter configured to count the number of occurrences of events of interest when the processor circuit processes the operations directed by each of the plurality of command sets, wherein each number corresponds to one of the events of interest, wherein the operations directed by each of the plurality of command sets are repeatedly processed until the number of all events of interest are counted for the operations directed by each of the plurality of command sets, and wherein, after counting the number of all events of interest for a first operation directed by a first command set in the plurality of command sets, a second operation directed by a second command set in the plurality of command sets is processed.

[0012] In addition, the consistency of commands and data for playback can be improved. Therefore, playback can be achieved based on consistent commands and data, and playback results can be easily correlated and matched with each other. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The above and other objects and features of the present disclosure will become apparent from the following description with reference to the accompanying drawings.

[0014] Figure 1is a block diagram illustrating an example configuration of an electronic system including a processor device according to some example embodiments.

[0015] Figure 2 Is the description and Figure 1 A conceptual diagram of example operations associated with a processor device.

[0016] Figure 3 Is used to describe Figure 1 A conceptual diagram of example operations associated with a processor device.

[0017] Figure 4 It is used to describe Figure 3 A conceptual diagram of example relationships between function calls and command sets for example operations.

[0018] Figure 5 It is used to describe the collection of Figure 1 A conceptual diagram of an example method for providing performance information of the operation of a graphics processor device.

[0019] Figure 6 is shown with Figure 1 A block diagram of an example configuration associated with a graphics processor device.

[0020] Figure 7 It describes the collection of Figure 6 A flow chart of an example method for providing performance information of the operation of a graphics processor device.

[0021] Figure 8 It is used to describe the collection of items with a quantity greater than Figure 6 A conceptual diagram of the replay of the performance information corresponding to the number of events of the register.

[0022] Fig. 9 It is used to describe Figure 6 A conceptual diagram of an example recap of the operation of a graphics processor device.

[0023] Fig.10 is described by Fig. 9 An example recap is a flowchart of an example method for collecting performance information.

[0024] Fig.11 Is used to describe Fig. 9 and 10 Concept diagram of an example reenactment of .

[0025] Figures 12 to 14 It is used to describe Figure 6 A conceptual diagram of an example recap of the operation of a graphics processor device.

[0026] Fig.15 is described by Figures 12 to 14An example recap is a flowchart of an example method for collecting performance information.

[0027] Fig.16 , 17A and 17B are used to describe Figures 12 to 15 An example replay is used to illustrate a conceptual diagram of an example method for managing count values.

[0028] Fig.18 Is used to describe Figures 12 to 15 Concept diagram of an example reenactment of .

[0029] Fig.19 and 20 It is used to describe Figures 12 to 15 A conceptual diagram of an example relationship between a command set and counter configuration values ​​is shown in FIG. DETAILED DESCRIPTION

[0030] Hereinafter, example embodiments will be described in detail and clearly with reference to the accompanying drawings.

[0031] Figure 1 1 is a block diagram illustrating an example configuration of an electronic system 1000 including processor devices 1100 and 1400 according to some example embodiments.

[0032] The electronic system 1000 may include a main processor device 1100, a system memory 1200, a storage device 1300, a graphics processor device 1400, a display device 1405, a buffer memory 1500, a communication block 1600, a user interface 1700, and a bus 1005. For example, the electronic system 1000 may be one of a desktop computer, a laptop computer, a tablet computer, a smart phone, a wearable device, an electric vehicle, a home appliance, and / or the like.

[0033] The main processor 1100 may perform various logic / arithmetic operations to control the overall operation of the electronic system 1000. For example, the main processor device 1100 may include an electronic circuit such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC). For example, the main processor device 1100 may include one or more processor cores and may be implemented with a general-purpose processor or an application processor.

[0034] The system memory 1200 may store data processed or to be processed by the main processor device 1100. For example, the system memory 1200 may include: a volatile memory such as a static random access memory (SRAM), a dynamic RAM (DRAM), or a synchronous DRAM (SDRAM); and / or a non-volatile memory such as a phase change RAM (PRAM), a magnetoresistive RAM (MRAM), a resistive RAM (ReRAM), or a ferroelectric RAM (FRAM).

[0035] The storage device 1300 can store data regardless of whether power is supplied. For example, the storage device 1300 may include a storage medium such as a solid state drive (SSD), a card memory, an embedded memory, or the like.

[0036] The graphics processor device 1400 may be configured to process specific types of operations. For example, the graphics processor device 1400 may process operations specific to graphics processing to display image information on the display device 1405. For example, the graphics processor device 1400 may perform operations specific to graphics processing by using parallel processors to process large amounts of graphics data. The graphics processor device 1400 may include electronic circuits such as FPGAs, ASICs, fixed / reconfigurable logic circuits, etc. to perform operations.

[0037] The display device 1405 may provide image information to a user based on the output of the graphics processor device 1400. For example, the display device 1405 may be implemented with an organic light emitting diode (OLED) display device, an active matrix OLED (AMOLED) display device, and / or the like.

[0038] The buffer memory 1500 may store data processed or to be processed by the graphics processor device 1400. For example, the buffer memory 1500 may include: a volatile memory such as SRAM, DRAM, or SDRAM; and / or a nonvolatile memory such as PRAM, MRAM, ReRAM, or FRAM.

[0039] In some example embodiments, Figure 1 As shown, the graphics processor device 1400 may be separated from the main processor device 1100. For example, the main processor device 1100 may be a central processing unit (CPU), and the graphics processor device 1400 may be a graphics processing unit (GPU). For example, the graphics processor device 1400 and the buffer memory 1500 may be implemented with one graphics card module.

[0040] In some example embodiments, Figure 1 Unlike the example shown in , the graphics processor device 1400 may be implemented as one chip or module together with the main processor device 1100. For example, the application processor may be implemented with a system on chip (SoC) and may include the configuration of the main processor device 1100 and the graphics processor device 1400.

[0041] In some example embodiments, Figure 1 As shown, the buffer memory 1500 may be separated from the system memory 1200. In other example embodiments, Figure 1Unlike the illustrated example, the buffer memory 1500 may be implemented with one memory together with the system memory 1200 , and the one memory may be shared by the main processor device 1100 and the graphics processor device 1400 .

[0042] In this way, the configuration of the electronic system 1000 may be variously changed or modified. Figure 1 The example configurations are for ease of understanding and are not intended to be limiting.

[0043] The communication block 1600 may support at least one of various wireless communication protocols and / or various wired communication protocols to communicate with external devices / systems of the electronic system 1000. The user interface 1700 may include various input interfaces and various output interfaces for facilitating communication between a user and the electronic system 1000.

[0044] The bus 1005 may provide a communication path between components of the electronic system 1000. The components of the electronic system 1000 may exchange data with each other according to a bus format of the bus 1005. For example, the bus format may include one or more of various interface protocols, such as Universal Serial Bus (USB), Small Computer System Interface (SCSI), Peripheral Component Interconnect Express (PCIe), Mobile PCIe (M-PCIe), Serial Advanced Technology Attachment (SATA), Serial Attached SCSI (SAS), and / or the like.

[0045] The main processor device 1100 and the system memory 1200 may constitute a host system 1002. The host system 1002 may access other components of the electronic system 1000 through a bus 1005. For example, using the bus 1005, the host system 1002 may communicate with the graphics processor device 1400 and / or may access the buffer memory 1500 so that the display device 1405 displays image information. In this example, the graphics processor device 1400 may be understood as a slave device of the host system 1002.

[0046] The main processor device 1100 and the graphics processor device 1400 may be implemented according to an exemplary embodiment of the present disclosure. Figures 2 to 20 Example configurations and example operations associated with the main processor device 1100 and the graphics processor device 1400 are described.

[0047] In the following description, example embodiments associated with the main processor device 1100 and the graphics processor device 1400 are provided, but the embodiments are not limited thereto. It can be easily understood that the example embodiments are used for any type of processor device, whether currently developed or developed in the future. The following description is provided to facilitate better understanding and is not restrictive.

[0048] Figure 2 Is the description and Figure 1 A conceptual diagram of example operations associated with processor devices 1100 and 1400.

[0049] The storage device 1300 may store data of the application AP and data of the GPU driver GD. The application AP may be software and / or firmware that enables the electronic system 1000 to perform operations defined by the program code of the application AP to provide services to the user. For example, the application AP may include an operating system and / or user applications (e.g., multimedia evolution applications, video game applications, etc.). As used herein, the term "program code" may refer to instructions written in a programming language (e.g., source code), which may be converted into a machine language (e.g., machine or executable code) for execution by a computer.

[0050] The user may be an end user of the electronic system 1000. Alternatively, the user may be a designer of the electronic system 1000 or the processor devices 1100 and 1400, or may be a developer of the application AP.

[0051] The GPU driver GD may be software and / or firmware configured to operate or control the graphics processor device 1400. The GPU driver GD may provide a hardware component (e.g., the main processor device 1100) of the electronic system 1000 that is interfaced with the graphics processor device 1400, and the GPU driver GD may allow the application AP to access the hardware functions of the graphics processor device 1400.

[0052] For example, a request for executing the application AP may be provided to the GPU driver GD for the graphics processor device 1400. For example, in response to a specific condition being satisfied, the request may be received from a user through the user interface 1700, or the request may be generated within the electronic system 1000. In response to the request received by the GPU driver GD, data of the application AP may be loaded to the system memory 1200.

[0053] The data of the GPU driver GD may also be loaded into the system memory 1200. The data of the GPU driver GD may be loaded when the operation of the electronic system 1000 is started (e.g., when the electronic system 1000 is booted); or the data of the GPU driver GD may be loaded when an interface with the graphics processor device 1400 is required.

[0054] When the data of the GPU driver GD is loaded into the system memory 1200, the main processor device 1100 may process an instruction set guided by the program code of the GPU driver GD. Therefore, the GPU driver GD may be executed on the host system 1002 according to the operation of the main processor device 1100.

[0055] For example, the program code of the application AP may include a portion configured to use the hardware function of the graphics processor device 1400. The portion may be processed at the graphics processor device 1400. To this end, the portion to be processed at the graphics processor device 1400 may be provided to the GPU driver GD.

[0056] The GPU driver GD may allocate a task to the graphics processor device 1400 based on a portion of a program code of the application AP to be processed by the graphics processor device 1400. The task may indicate an amount of work to be performed using a hardware function provided by the graphics processor device 1400.

[0057] The graphics processor device 1400 may include one or more functional units FU. The functional unit FU may be configured to process tasks assigned from the GPU driver GD. To this end, each functional unit FU may include one or more processor cores and / or one or more logic circuits. The logic circuit may be fixed, programmable and / or reconfigurable. Here, the functional unit FU may also be referred to as a processor circuit or a processor unit.

[0058] For example, the functional unit FU may include a primitive assembler for constructing primitives based on vertex data, a rasterizer for generating fragment data and coverage data based on the primitives, a shader core for processing an instruction set guided by a shader program, a special operation unit for performing special functions (e.g., triangle copying, pixel blending, etc.), and / or the like. For example, the functional unit FU may provide the function of general purpose computing on a GPU (GPGPU).

[0059] However, the above examples are provided for better understanding and are not restrictive. The functional unit FU may include various types of functional units to perform operations associated with graphics processing. The functional unit FU may return the result of the processing task to the GPU driver GD. Thus, the program code portion of the application AP that requires the hardware function of the graphics processor device 1400 may be processed.

[0060] For example, the main processor device 1100 may control the graphics processor device 1400 so that the graphics processor device 1400 performs an operation. The buffer memory 1500 may store an operation result (e.g., a result of processing a task) generated by the graphics processor device 1400, and the main processor device 1100 may access the buffer memory 1500 to obtain the operation result. Therefore, the operation result from the graphics processor device 1400 may be provided to the GPU driver GD.

[0061] For example, the program code of the application AP may include a portion to be processed by the main processor device 1100. The portion of the program code to be processed at the main processor device 1100 may direct and control general arithmetic / logic operations that are not related to graphics processing. Additionally or alternatively, the portion to be processed at the main processor device 1100 may direct arithmetic / logic operations to generate texture data to be used in graphics processing of the graphics processor device 1400.

[0062] In this manner, the main processor device 1100 and the graphic processor device 1400 may execute and process operations defined by the program code of the application AP. The application AP may provide services to the user based on the results of executing / processing the operations.

[0063] Figure 3 Is used to describe Figure 1 A conceptual diagram of example operations associated with processor devices 1100 and 1400.

[0064] The program code of the application AP may include a portion to be processed at the main processor device 1100 and a portion to be processed at the graphics processor device 1400. Based on the program code portion to be processed at the main processor device 1100, the main processor device 1100 may process operations required for the application AP.

[0065] In some example embodiments, the program code portion to be processed in the graphics processor device 1400 may be written based on a graphics application programming interface (API). For example, the program code portion to be processed in the graphics processor device 1400 may be written based on an API library or framework such as Direct 3D, OpenGL, EGL, OpenCL, etc. In these example embodiments, when the application AP is executed, a function call may be generated from the program code portion to be processed in the graphics processor device 1400.

[0066] However, the above examples are provided for better understanding and are not limiting. The program code portion to be processed by the graphics processor device 1400 may be written based on other types of libraries or frameworks, or may be written in general program code without a specific library or framework. Regardless of the way the program code is written, a function, method, or any other type of module may be called when executing the application AP.

[0067] The function call may be input to the GPU driver GD. The GPU driver GD may convert the function call into a command set. The command set may be a machine instruction and may be generated by changing the function call into a format that can be processed and recognized by the graphics processor device 1400. For example, the graphics processor device 1400 may not directly process the function call and may understand and process the command set prepared by the GPU driver GD.

[0068] The graphics processor device 1400 may receive the command set (e.g., via the bus 1005) and may process the operations directed by the received command set. For example, in response to each received command set, the graphics processor device 1400 may perform the operations included in the received command set and directed by the received command set commands. In this way, the graphics processor device 1400 may perform operations corresponding to the program code portion of the program code of the application AP to be processed by the graphics processor device 1400.

[0069] Figure 4 It is used to describe Figure 3 A conceptual diagram of example relationships between function calls and command sets for example operations.

[0070] For example, M function calls may constitute a function call group. For example, the first to Mth function calls may constitute a first function call group (e.g., API function call group 1). Similarly, the second to Nth function call groups may include several separate function calls. However, in some examples, the number of function calls constituting each function call group may be different from each other.

[0071] For example, a function call group may be converted into a command set. For example, a first command set may be generated based on function calls of a first function call group, and a second command set may be generated based on a second function call group. A function call group may include function calls that may constitute a command set. Figure 4 As shown in the example, command set 1 can be generated based on API function call group 1, command set 2 can be generated based on API function call group 2, command set 3 can be generated based on API function call group 3, command set (N-1) can be generated based on API function call group (N-1), and command set N can be generated based on API function call group N.

[0072] A command set may be configured in a grouping unit or in a batch unit. A command set may correspond to an input to a command queue (e.g., Figure 6 A unit of a command queue (CQ) and is managed in the command queue.

[0073] The commands included in one command set may be input to the command queue together and may be processed together continuously in one processing interval. For example, commands (e.g., machine instructions) included in a first command set may be processed continuously in a first single processing interval, and commands included in a second command set may be processed continuously in a second single processing interval.

[0074] Figure 5 It is used to describe the collection of Figure 1A conceptual diagram of an example method of providing performance information of an operation of a graphics processor device 1400.

[0075] When the graphics processor device 1400 processes the operations directed by the command set for the function call, various events may occur. An event may be an action or situation detected by the program. For example, an event may include hardware-related states, such as a cache miss (i.e., a state in which the required data is not stored in the cache memory), a bus conflict (i.e., a state in which a conflict occurs between data paths through the bus), a process idle state (i.e., a state in which a particular functional unit or processor is idle and no operations are being processed), and the like.

[0076] For example, events may include graphics-related states such as vertex counts (i.e., the number of input or output vertices associated with a particular functional unit), primitive counts (i.e., the number of input or output primitives associated with a particular functional unit), and / or the like. However, the above examples are provided to facilitate better understanding and are not intended to be limiting. Events may include various states that occur when the graphics processor device 1400 processes an operation.

[0077] Events may affect the operational performance and operational characteristics of the graphics processor device 1400. For example, frequent cache misses may reduce operational performance. Therefore, collecting performance information (e.g., information associated with events that occur when the graphics processor device 1400 performs operations and how many times each event occurs) can be beneficial for analyzing and improving the performance and characteristics of the application AP and the graphics processor device 1400.

[0078] For example, the collected performance information can be referenced to analyze the cause of the operation bottleneck required by the application AP and optimize the program code of the application AP. For example, the collected performance information can be referenced to debug errors or exceptions that occur when performing operations required by the application AP.

[0079] In this way, the collected performance information can be used in different ways to improve the services provided by the application AP. For example, the electronic system 1000 can automatically perform analysis / improvement work based on the collected performance information. For example, the electronic system 1000 can store the collected performance information in the form of a file or a database (for example, in the storage device 1300), or can output the collected performance information to the user through the display device 1405 or the user interface 1700. The user can manually perform analysis / improvement work with reference to the collected performance information.

[0080] Collecting performance information and performing analysis / improvement work may be referred to as performance profiling. Performance profiling may be performed on all or part of the program code processed by the graphics processor device 1400 in the program code of the application AP. For example, a user may select a starting point and an end point of a portion of the program code for performance profiling. In this example, performance profiling may be performed on function calls corresponding to the performance profiling target between the starting point and the end point. For example, in Figure 5 In the embodiment, performance analysis is performed on the function calls constituting the second to (N-1)th function call groups (eg, API function call group 2, API function call group 3, to API function call group (N-1)).

[0081] Alternatively, the user may specify a target for performance analysis of frame units obtained as a result of rendering.

[0082] Figure 6 is shown with Figure 1 A block diagram of an example configuration associated with a graphics processor device 1400 is shown.

[0083] In some example embodiments, the graphics processor device 1400 may include a scheduler 1410, function units 1431 to 1439, performance counters 1451 to 1459, and registers 1471 to 1479. Figure 6 The configuration of the graphics processor device 1400 may be changed or modified differently depending on the description of FIG. The graphics processor device 1400 may also include Figure 6 Components not shown, or may not be included Figure 6 One or more of the components shown in .

[0084] The scheduler 1410 may receive a command set from the GPU driver GD. The scheduler 1410 may manage commands of the received command set in a command queue CQ. The command queue CQ may be allocated in a storage area on the buffer memory 1500 to manage commands of each command set.

[0085] Functional units 1431 to 1439 may correspond to Figure 2 The function units 1431 to 1439 may process tasks assigned from the GPU driver GD. To this end, the scheduler 1410 may schedule commands (e.g., may arrange the order of processing commands or may establish a relationship between commands received from the GPU driver GD), so that the function units 1431 to 1439 may execute and process operations directed by each command set.

[0086] The operation results OR from the functional units 1431 to 1439 may be stored in the buffer memory 1500. The main processor device 1100 may access the buffer memory 1500 to obtain the operation results OR.

[0087] Performance counters 1451 to 1459 can count the number of times an event occurs when the functional units 1431 to 1439 process operations. For example, performance counters 1451 to 1459 can count the number of cache misses that occur when processing operations directed by a command set. In this way, performance information can be collected.

[0088] In some cases, the user or electronic system 1000 may be interested in the occurrence of a specific event among various events. For example, the user or electronic system 1000 may be interested in events that cause performance degradation, such as cache misses and processing idle states. Specific events may be referred to as events of interest. Collecting performance information may be performed for all events, or may be performed for certain events (e.g., events of interest).

[0089] For example, information associated with the counter configuration may be received at the scheduler 1410. For example, the counter configuration information may be received from a user through the user interface 1700, or may be generated in the electronic system 1000.

[0090] For example, the counter configuration information may be used to set the configuration (e.g., setting values, operating conditions, etc.) of performance counters 1451 to 1459, which are used to collect performance information associated with events of interest. For example, when the events of interest include cache misses, the counter configuration information may be used to set the configuration of the performance counters 1451 to 1459 to be suitable for counting the number of cache misses that occur for the functional units 1431 to 1439.

[0091] The scheduler 1410 may set the configuration of the performance counters 1451 to 1459 based on the counter configuration information so that the performance counters 1451 to 1459 count the number of events of interest. Based on the setting of the scheduler 1410, the performance counters 1451 to 1459 may count the number of events of interest that occur respectively for the processing operations directed by each command set.

[0092] Figure 6 An example configuration is shown in which performance counters 1451 to 1459 correspond to functional units 1431 to 1439, respectively. In this configuration, performance counters 1451 to 1459 can count the number of events of interest for operations processed by the respective functional units 1431 to 1439.

[0093] However, the embodiments are not limited to Figure 6 In some example embodiments, Figure 6 Different from the illustration of FIG. 14 , the configuration of the graphics processor device 1400 may be changed or modified in such a manner that one performance counter corresponds to a plurality of functional units, or a plurality of performance counters correspond to one functional unit.

[0094] The registers 1471 to 1479 may store count values. The count values ​​may correspond to the number of times counted by a corresponding one of the performance counters 1451 to 1459. For example, when the functional units 1431 to 1439 process an operation, the performance counters 1451 to 1459 may change or update the count values ​​stored in the registers 1471 to 1479 based on the number of times counted.

[0095] For example, when the functional units 1431 to 1439 complete the processing operation, the count values ​​CV that have been stored in the registers 1471 to 1479 may be stored in the buffer memory 1500. For example, the main processor device 1100 may access the buffer memory 1500 to obtain the count value CV. The count value CV may be collected as performance information, and performance analysis may be performed based on the count value CV.

[0096] Figure 7 It describes the collection of Figure 6 Flowchart of an example method of providing performance information of an operation of a graphics processor device 1400.

[0097] For example, the user 10 may select a start point and an end point of the performance analysis and may select an analysis configuration in some cases ( S110 ). For example, the user 10 may input information of a start point, an end point, and an analysis configuration to the electronic system 1000 through the user interface 1700 .

[0098] The analysis configuration may include various information associated with the conditions of the performance analysis. For example, the profiling configuration may include information associated with an event of interest. When the user 10 inputs the analysis configuration, the performance analysis may be provided for the event of interest.

[0099] For example, user 10 may request to execute application AP (S120). Main processor device 1100 may respond to the requested execution. Under the control of main processor device 1100, data of application AP may be loaded into system memory 1200, and operations defined by program code of application AP may be executed and processed. In some example embodiments, operations S110 and S120 may be triggered within electronic system 1000 in response to satisfying a specific condition.

[0100] The main processor device 1100 may control the transfer of a program code portion to be processed at the graphics processor device 1400 in the program code of the application AP (S130). Under the control of the main processor device 1100, the GPU driver GD may generate a command set based on a function call generated according to the execution of the application AP, and may also generate counter configuration information based on the analysis configuration (S140).

[0101] In the graphics processor device 1400, the scheduler 1410 may receive the command set and the counter configuration information. The scheduler 1410 may schedule the commands of the command set and may set the configurations of the performance counters 1451 to 1459 (S150). In addition, the scheduler 1410 may dispatch the commands to the function units 1431 to 1439 (S160).

[0102] Therefore, the functional units 1431 to 1439 can process the operations guided by the commands through the command set unit. For example, the commands of a given command set unit can be processed by one functional unit 1431 to 1439. The performance counters 1451 to 1459 can count the number of times that events of interest occur respectively when processing the operation (S170). For example, each performance counter 1451 to 1459 can count the number of times that corresponding events of interest occur when processing the operation. The counted number of times can be temporarily stored in registers 1471 to 1479, and the count value CV can be stored in the buffer memory 1500 after the operation processing is completed (S180).

[0103] The main processor device 1100 may generate performance information or performance analysis results based on the count value CV stored in the buffer memory 1500 (S190). For example, the performance information or performance analysis results may be stored in the storage device 1300 including digital statistical information, or may be output in the form of a graph or table. For example, the user 10 may use the performance information or performance analysis results to analyze and improve the application AP (S199).

[0104] Figure 8 is used to describe a collection of numbers corresponding to a quantity greater than Figure 6 A conceptual diagram of the replay of performance information of the number of events of registers 1471, 1472 and 1479.

[0105] For better understanding, it will be assumed that the graphic processor device 1400 includes three (3) registers 1471, 1472, and 1479. Each of the registers 1471, 1472, and 1479 may store a value corresponding to the number of times one event is counted.

[0106] In some cases, the number of events of interest may be greater than the number of registers 1471, 1472, and 1479. For example, the user 10 or the electronic system 1000 may be interested in twelve (12) events. For example, the first, second, and third events may constitute a first event set. Similarly, the fourth to twelfth events may constitute a second to fourth event set. However, the number of registers and the number of events of interest may be changed or modified differently, and the present invention is not limited to the examples described in the present disclosure.

[0107] Meanwhile, the three registers 1471, 1472, and 1479 can store the number of times counted for three events of interest, and may not be able to store the number of times counted for all twelve events of interest. In this case, in order to count the number of times all 12 events of interest occur respectively, the operation guided by the program code of the application AP can be repeated four times between the start point and the end point.

[0108] For example, a first play may be provided so that the number of first, second, and third events is counted. Here, play may mean the execution and processing of operations guided by the program code of the application AP (i.e., guided by a command set) within a single specific interval (e.g., the interval between the start point and the end point). When the first play is performed, performance information may be collected for the first, second, and third events. Similarly, second to fourth play may be provided to count the number of fourth to twelfth events. For example, a second play may be performed to collect performance information for the fourth, fifth, and sixth events, a third play may be performed to collect performance information for the seventh, eighth, and ninth events, and a fourth play may be performed to collect performance information for the tenth, eleventh, and twelfth events.

[0109] Therefore, when the number of events of interest is greater than the number of registers, the operations directed by the program code of the application AP may be replayed to collect performance information for all events of interest. Here, replay may mean repeatedly executing the same evolution multiple times.

[0110] However, for each repetitive operation directed by each command set (i.e., for each evolution), the number of different events of interest may be counted. For example, the number of first, second, and third events may be counted for the first evolution, and the number of fourth, fifth, and sixth events may be counted for the second evolution. One evolution may be performed for one set of events.

[0111] When the number of registers increases, the number of repetitions can be reduced, and the efficiency of replay can be improved. However, when the number of registers increases, the cost of manufacturing the graphics processor device 1400 and the size of the graphics processor device 1400 may also increase. Therefore, the graphics processor device 1400 may include a limited number of registers 1471, 1472, and 1479.

[0112] Fig. 9 It is used to describe Figure 6 A conceptual diagram of an example recap of the operation of a graphics processor device 1400 is shown.

[0113] For example, performance information may be collected for function calls from the second function call group (e.g., API function call group 2) to the (N-1)th function call group (e.g., API function call group (N-1)) between the start point and the end point. In some implementations, replay may be performed based on the entire function call group (e.g., API function call group 2 to API function call group (N-1)).

[0114] For example, a first evolution associated with a first set of events may be executed to process operations corresponding to the full function call group. During the first evolution (e.g., evolution 1), performance information may be collected for the first, second, and third events (e.g., event set 1). After the first evolution is completed, a second evolution associated with a second set of events may be executed to process operations corresponding to the full function call group. During the second evolution (e.g., evolution 2), performance information may be collected for the fourth, fifth, and sixth events (e.g., event set 2).

[0115] Similarly, after the second evolution is completed, each of the third and fourth evolutions can be performed based on the full function call group. During the third and fourth evolutions (e.g., evolution 3 and evolution 4), performance information can be collected for the seventh to twelfth events (e.g., event set 3 and event set 4).

[0116] Fig.10 is described by Fig. 9 An example flowchart of an example method for collecting performance information is repeated in the example. For example, Fig.10 An example method can be found in Figure 7 Operation S110 and operation S120 are performed thereafter.

[0117] When executing the application AP, the main processor device 1100 may capture a function call generated from a program code portion of the application AP to be processed by the graphics processor device 1400. Here, capturing may mean, for example, hooking the generated function call to identify which function call is generated. The main processor device 1100 may retain (e.g., store) information of the captured function call in the system memory 1200 (S130a-1).

[0118] The main processor device 1100 (or, in some example embodiments, the GPU driver GD or the graphics processor device 1400) may determine whether all count values ​​have been collected (S130a-2). If not, replay may be performed for count values ​​that have not been collected. Therefore, if all count values ​​have not been collected (S130a-2, No), the main processor device 1100 may input a full function call for the Kth evolution to the GPU driver GD (S130a-3).

[0119] Therefore, the program part to be processed in the graphics processor device 1400 can be transmitted. At the same time, the transmission of the function call can be accompanied by the transmission of the analysis configuration information. The GPU driver GD can generate a command set based on the full function call, and can generate counter configuration information based on the analysis configuration (S140a).

[0120] Afterwards, in the graphics processor device 1400, the scheduler 1410 may schedule commands of the command set and may set configurations of the performance counters 1451 to 1459 based on the counter configuration information (S150a). The commands may be dispatched to the function units 1431 to 1439 according to the scheduling result (S160a).

[0121] While the functional units 1431 to 1439 process the operations directed by the commands, the performance counters 1451 to 1459 may count the number of times the events of interest respectively occur (S170a). The counted number of times may be temporarily stored in a corresponding one of the registers 1471, 1472, and 1479, and after the operation processing of the K-th evolution is completed, the count value CV may be stored in the buffer memory 1500 (S180a).

[0122] Afterwards, the main processor device 1100 (or, in some example embodiments, the GPU driver GD or the graphics processor device 1400) may determine again whether all count values ​​have been collected (S130a-2). If not, operations S130a-3 to S180a may be repeated. Fig. 9 and 10 In the example of . The replay can be based on the full function call stored in the system memory 1200.

[0123] When all count values ​​are collected (S130a-2, yes), the main processor device 1100 (or, in some example embodiments, the GPU driver GD or the graphics processor device 1400) can establish correlations between count values ​​CV associated with events of interest (S190a-1). Events of different event sets can be observed during different evolutions of the same full function call, so the main processor device 1100 (or, in some example embodiments, the GPU driver GD or the graphics processor device 1400) can associate and match the count values ​​CV with each other for various factors (e.g., timing, causality, etc.) to obtain appropriate replay results and performance information. The main processor device 1100 can generate performance information or performance analysis results based on the count values ​​CV and the correlation (S190a-2).

[0124] Fig.11 Is used to describe Fig. 9 and 10 Concept diagram of an example reenactment of .

[0125] exist Fig. 9 and 10 In the example of , the replay can be based on a full function call group generated from the program code of the application AP. In order to observe different events for each evolution, the configuration of the performance counters 1451 to 1459 can be changed for each repetition.

[0126] For example, for the first evolution, the configuration of performance counters 1451 to 1459 may be set to observe the events of interest of the first event set. Thereafter, for the second evolution, the configuration of performance counters 1451 to 1459 may be set to observe the events of interest of the second event set. In this way, for the third and fourth evolutions, the configuration of performance counters 1451 to 1459 may be set to observe the events of interest of the third and fourth event sets, respectively.

[0127] against Fig. 9 and 10 For example, the system memory 1200 may maintain information of the full function call group, and the GPU driver GD may convert the full function call group into a command set for each evolution. Therefore, a large-capacity storage area may be used on the system memory 1200 for replay. In addition, converting the full function call group and transmitting the command set to the graphics processor device 1400 for each evolution may reduce the efficiency of performance analysis.

[0128] In addition, function calls may be accompanied by arguments or parameters used in the operations directed by each function. Maintaining not only the information of the function call group but also the information of the arguments or parameters may also use a large storage area on the system memory 1200. For example, when the arguments or parameters include graphics data (e.g., texture data), replay may use a relatively large storage area. When a large amount of storage area of ​​the system memory 1200 is allocated for replay, processing of other operations may be delayed.

[0129] In some cases, when the electronic system 1000 is implemented with a mobile or portable device, the system memory 1200 may have a small capacity. In this case, the system memory 1200 may not be able to store a large amount of information, and the length of the function call interval targeted for performance analysis may be shortened. Therefore, it may be difficult to collect sufficient performance information.

[0130] In addition, the GPU driver GD may generate a new command set for each evolution. In this case, a different command set may be generated for each evolution depending on the runtime state and non-deterministic characteristics of the main processor device 1100. For example, the order of scheduling commands may change, or the causal relationship between commands may change. In this case, it may be difficult to correlate between count values, or the correlation between count values ​​may be inaccurate.

[0131] Figures 12 to 14 It is used to describe Figure 6 A conceptual diagram of an example recap of the operation of a graphics processor device 1400 is shown.

[0132] For example, performance information may be collected for function calls from the second function call group to the (N-1)th function call group between the start point and the end point. Figures 12 to 14 In an example embodiment, replay can be performed based on command sets, rather than based on full function call groups. That is, the same evolution can be repeated (e.g., replayed) for each command set, rather than repeated for the full function call group.

[0133] First, refer to Fig.12 , replay may be performed based on commands of a second command set (e.g., command set 2) generated from a second function call group (e.g., API function call group 2). A first evolution (e.g., evolution 1) associated with a first event set (e.g., event set 1) may be partially executed to process operations directed by a second command set (e.g., command set 2). After the partial first evolution is completed, a second evolution (e.g., evolution 2) associated with a second event set (e.g., event set 2) may be partially executed to process operations directed by the second command set.

[0134] Similarly, after completing part of the second evolution, the third evolution (e.g., Evolution 3) associated with the third event set (e.g., Event Set 3) may be partially executed, and then the fourth evolution (e.g., Evolution 4) associated with the fourth event set (e.g., Event Set 4) may be partially executed. That is, each evolution may not be executed based on the full function call group, but each evolution may be partially executed to repeatedly process the operations directed by the second command set (this may be referred to as partial replay). When each evolution is partially and repeatedly executed, the number of all events of interest may be counted for the operations directed by the second command set.

[0135] For example, the events of interest (e.g., events of the first event set) observed in a first repetition (e.g., part of a first evolution) of the commands of the second command set may be different from the events of interest (e.g., events of the second event set) observed in a second repetition (e.g., part of a second evolution) of the commands of the second command set. Thus, the events of interest corresponding to the number of times counted in the first repetition may be different from the events of interest corresponding to the number of times counted in the second repetition. For each repetition directed by the second command set, the number of different events of interest may be counted.

[0136] Afterwards, refer to Fig.13 , replay may be performed based on commands of a third command set (eg, command set 3) generated from a third function call group (eg, API function call group 3). Fig.12 Partial replay, and partial execution Fig.13 to repeat the processing of the operations directed by the third command set.

[0137] For example, a first evolution (e.g., Evolution 1) associated with a first event set (e.g., event set 1) may be partially executed to process operations directed by a third command set (e.g., command set 3), then a second evolution (e.g., Evolution 2) associated with a second event set (e.g., event set 2) may be partially executed to process operations directed by the third command set (e.g., command set 3), then a third evolution (e.g., Evolution 3) associated with a third event set (e.g., event set 3) may be partially executed to process operations directed by the third command set (e.g., command set 3), and then a fourth evolution (e.g., Evolution 4) associated with a fourth event set (e.g., event set 4) may be partially executed to process operations directed by the third command set (e.g., command set 3).

[0138] Can be Fig.12 Execute after the partial replay is completed Fig.13 Therefore, after counting the number of all events of interest for the operations directed by the second command set, the operations directed by the third command set can be processed. Fig.13In the partial replay, the operations directed by the third command set may be repeatedly processed so that the number of all events of interest is counted for the operations directed by the third command set.

[0139] In this manner, partial replay may be performed based on the commands of the command set generated from each function call group.

[0140] Reference Fig.14 , a first replay (e.g., evolution 1) may be partially performed to repeatedly process operations directed by the (N-1)th command set (N-1) (e.g., command set (N-1)) generated by the (N-1)th function call group (e.g., API function call group (N-1)). The operation may be performed after counting the number of all events of interest for operations directed by the (N-2)th command set (e.g., command set (N-2)). Fig.14 For example, a first evolution (e.g., Evolution 1) associated with a first event set (e.g., event set 1) may be partially executed to process operations directed by an (N-1)th command set (e.g., command set (N-1)), then a second evolution (e.g., Evolution 2) associated with a second event set (e.g., event set 2) may be partially executed to process operations directed by an (N-1)th command set (e.g., command set (N-1)), then a third evolution (e.g., Evolution 3) associated with a third event set (e.g., event set 3) may be partially executed to process operations directed by an (N-1)th command set (e.g., command set (N-1)), then a fourth evolution (e.g., Evolution 4) associated with a fourth event set (e.g., event set 4) may be partially executed to process operations directed by an (N-1)th command set (e.g., command set (N-1)).

[0141] When partial replay is performed for all command sets, each evolution can be performed for operations directed by all command sets. Therefore, all evolutions can be performed so that the number of times all interesting events that occur respectively are counted for full function calls.

[0142] Fig.15 is described by Figures 12 to 14 Flowchart of an example method for collecting performance information by replaying an example of Figure 7 Operation S110 and operation S120 are performed after Fig.15 Example method of .

[0143] When executing the application AP, a function call may be generated from a program code portion of the application AP to be processed in the graphics processor device 1400. The main processor device 1100 may input the function call to the GPU driver GD (S130b). Meanwhile, the transmission of the function call may be accompanied by the transmission of information of the analysis configuration.

[0144] The GPU driver GD may generate a command set based on the function call, and may generate counter configuration information based on the analysis configuration (S140b). In the graphics processor device 1400, the scheduler 1410 may receive the command set and the counter configuration information from the GPU driver GD.

[0145] and Fig. 9 and 10 Unlike the example Figures 12 to 15 In an exemplary embodiment of the present invention, the scheduler 1410 may receive only one command set from the GPU driver GD. The received command set may be managed in a command queue CQ.

[0146] The scheduler 1410 may schedule commands of the command set (S150b-1), and may set configurations of the performance counters 1451 to 1459 based on the counter configuration information (S150b-2). The commands may be dispatched to the function units 1431 to 1439 according to the result of the scheduling (S160b).

[0147] While the functional units 1431 to 1439 process the operations directed by the commands, the performance counters 1451 to 1459 may count the number of times the events of interest respectively occur (S170b-1). The counted number of times may be temporarily stored in the registers 1471, 1472, and 1479, and the count value CV may be stored in the buffer memory 1500 after the operation processing is completed (S180b).

[0148] Afterwards, the graphics processor device 1400 (or, in some example embodiments, the GPU driver GD or the main processor device 1100) may determine whether all count values ​​have been collected for one command set (S170b-2). If not (S170b-2, No), operations S150b-2 to S180b may be repeated.

[0149] The repetition of operations S150b-2 to S180b may be provided to count the number of different events of interest for the same command set. In the repetition of operations S150b-2 to S180b, the commands of a command set may be repeatedly scheduled and processed so that the number of all events of interest is counted for the operations directed by a command set. To this end, in operation S150b-2, the scheduler 1410 may reconfigure the performance counters 1451 to 1459 for each repetition of a command set.

[0150] For example, when the number of all events of interest is not completely counted for the operation directed by the second command set even though the operation directed by the second command set is processed, the scheduler 1410 may change the configuration of the performance counters 1451 to 1459 and may repeatedly schedule the commands of the second command set so that the number of events of interest corresponding to the number of times not counted respectively is counted. For example, the scheduler 1410 may change the configuration of the performance counters 1451 to 1459 and may repeatedly schedule the commands of the second command set so that the events of interest that have not been counted are counted. Therefore, for each evolution of the partial replay, the number of different events of interest may be counted.

[0151] In this way, Figures 12 to 15 In an example embodiment, replay can be performed based on units of command sets managed in a command queue CQ, rather than based on full function calls. Command set-based replay can be performed based on commands of command sets managed in a command queue CQ, without repeatedly receiving command sets from a GPU driver GD.

[0152] When all count values ​​are collected for one command set (S170b-2, yes), the graphics processor device 1400 (or, in some example embodiments, the GPU driver GD or the main processor device 1100) may determine whether to process all command sets (S170b-3). If all command sets are not processed (S170b-3, no), operations S150b-1 to S180b may be repeated.

[0153] Repetition of operations S150b-1 to S180b may be provided to count the number of different events of interest for all command sets. In operation S150b-1, the scheduler 1410 may schedule commands of a new command set so that the number of events of interest is counted for operations directed by different command sets.

[0154] For example, after counting the number of all events of interest for operations directed by the second command set, the scheduler 1410 may schedule commands of the third command set. Therefore, the functional units 1431 to 1439 may process operations directed by the third command set, and the performance counters 1451 to 1459 may count the number of events of interest that respectively occur for the third command set.

[0155] When all command sets are processed, the main processor device 1100 (or, in some example embodiments, the GPU driver GD or the graphics processor device 1400) may establish a correlation between count values ​​CV associated with events of interest (S190B-1). Figures 12 to 15In an example embodiment, a count value corresponding to an event may be counted separately for each command set, and thus the main processor device 1100 (or, in some example embodiments, the GPU driver GD or the graphics processor device 1400) may be associated with each other and match the count values ​​corresponding to an event.

[0156] For example, for the corresponding event, the number of times counted for the operation directed by the second command set can be added to the number of times counted for the operation directed by the third command set. Figures 16 to 17B Further description. The main processor device 1100 may generate performance information or performance analysis results based on the count value CV and the correlation (S190b-2).

[0157] Figures 16 to 17B It is used to describe Figures 12 to 15 An example replay is used to illustrate a conceptual diagram of an example method for managing count values.

[0158] See also Fig.16 For example, after partially executing a first evolution (e.g., evolution 1) for operations directed by a second command set (e.g., command set 2) for events of interest of a first event set (e.g., event set 1), registers 1471, 1472, and 1479 may store count values ​​CV[E1][1], CV[E2][1], and CV[E3][1], respectively. The count values ​​CV[E1][1], CV[E2][1], and CV[E3][1] may correspond to the number of first, second, and third events E1, E2, and E3 of the first event set that occurred when processing operations directed by the second command set, respectively.

[0159] After completing the partial first evolution and before executing the second evolution (e.g., Evolution 2) for the operations directed by the second command set for the events of interest of the second event set (e.g., Event Set 2), registers 1471, 1472, and 1479 may output count values ​​CV[E1][1], CV[E2][1], and CV[E3][1], respectively. Therefore, the count values ​​CV[E1][1], CV[E2][1], and CV[E3][1] may be stored in the buffer memory 1500. After the count values ​​CV[E1][1], CV[E2][1], and CV[E3][1] are output to the buffer memory 1500, the partial second evolution may be executed.

[0160] See also Figures 16 to 17BIn this way, the second to fourth evolutions (e.g., Evolution 2 to Evolution 4) may be partially performed, and count values ​​CV[E4][1] to CV[E12][1] may be temporarily stored in registers 1471, 1472, and 1479. The count values ​​CV[E4][1] to CV[E12][1] may respectively correspond to the number of times the fourth to twelfth events E4 to E12 of the second to fourth event sets (e.g., event set 2 to event set 4) occur when processing operations directed by the second command set.

[0161] After completing the operation processing of the second to fourth evolutions (e.g., Evolution 2 to Evolution 4) associated with the second command set, count values ​​CV[E4][1] to CV[E12][1] may be stored in the buffer memory 1500. After completing the replay of the second command set and counting the number of times of all events of interest E1 to E12, the first evolution may be performed on the operation directed by the third command set (e.g., command set 3) for the events of interest E1, E2, and E3 of the first event set.

[0162] See also Fig.17A In some example embodiments, the performance counters 1451 to 1459 may count the number of occurrences of the events of interest E1, E2, and E3 when processing the operation directed by the third command set without reading the count values ​​CV[E1][1] to CV[E3][1] stored in the buffer memory 1500. In this case, the registers 1471, 1472, and 1479 may store the count values ​​CV[E1][2], CV[E2][2], and CV[E3][2]. Thereafter, before the second evolution is performed for the operation directed by the third command set for the events of interest E4, E5, and E6 of the second event set, the count values ​​CV[E1][2], CV[E2][2], and CV[E3][2] may be stored in the buffer memory 1500.

[0163] In some example embodiments, count values ​​CV[E1][1] and CV[E1][2] may be managed separately in the buffer memory 1500. At the same time, the sum of count values ​​CV[E1][1] and CV[E1][2] may correspond to the number of times the event of interest E1 occurs for processing operations directed by the second and third command sets. Therefore, when the main processor device 1100 obtains count values ​​CV[E1][1] and CV[E1][2] from the buffer memory 1500, respectively, the main processor device 1100 may add count values ​​CV[E1][1] and CV[E1][2] to provide the number of times the event of interest E1 occurs as performance information or a performance analysis result.

[0164] See also Fig. 17BIn some example embodiments, before the first evolution of the operation directed by the third command set is performed for the events of interest E1, E2, and E3 of the first event set, the count values ​​CV[E1][1] to CV[E3][1] of the buffer memory 1500 may be read to the registers 1471, 1472, and 1479. When processing the operation directed by the third command set, the performance counters 1451 to 1459 may count the number of occurrences of the events of interest E1, E2, and E3 to change (e.g., update) the count values ​​CV[E1][1] to CV[E3][1] of the registers 1471, 1472, and 1479.

[0165] As a result, registers 1471, 1472, and 1479 may store the sum of the following count values, respectively: “CV[E1][1]+CV[E1][2]”, “CV[E2][1]+CV[E2][2]”, and “CV[E3][1]+CV[E3][2]”. The sum of the count values ​​“CV[E1][1]+CV[E1][2]”, “CV[E2][1]+CV[E2][2]”, and “CV[E3][1]+CV[E3][2]” may correspond to the number of times events of interest E1, E2, and E3 occur for processing operations directed by the second and third command sets, respectively.

[0166] Thereafter, before performing a second evolution of the operations directed by the third command set for the events of interest E4, E5, and E6 of the second event set, the sums of the count values ​​“CV[E1][1]+CV[E1][2]”, “CV[E2][1]+CV[E2][2]”, and “CV[E3][1]+CV[E3][2]” may be stored in the buffer memory 1500. In addition, the count values ​​CV[E4][1] to CV[E6][1] of the buffer memory 1500 may be read to registers 1471, 1472, and 1479.

[0167] In this manner, in some example embodiments, count values ​​CV[E1][1] and CV[E1][2] may be managed as the sum “CV[E1][1]+CV[E1][2]”. The main processor device 1100 may obtain the sum “CV[E1][1]+CV[E1][2]” directly from the buffer memory 1500. The main processor device 1100 may use the sum “CV[E1][1]+CV[E1][2]” to provide the number of occurrences of the event of interest E1 as performance information or a performance analysis result.

[0168] Fig.18 Is used to describe Figures 12 to 15 Concept diagram of an example reenactment of .

[0169] exist Figures 12 to 15In an example embodiment, a function call generated based on a program code of an application AP may be converted into a command set. Each command set may be provided once to the graphics processor device 1400. Replay may be based on units of command sets managed in a command queue CQ.

[0170] For example, in order to collect performance information for the second command set and perform performance analysis, the operation guided by the second command set can be replayed. The operation guided by the second command set can be repeated until the number of all events of interest is counted for the operation guided by the second command set. After completing the repetition of the operation guided by the second command set, the operations guided by the third to (N-1)th command sets can be replayed based on the command set in a similar manner.

[0171] against Figures 12 to 15 In an exemplary embodiment, the buffer memory 1500 may retain the command queue CQ, and the system memory 1200 may not retain the information of the function call. Therefore, in the case of providing a limited number of registers, replay can be implemented even with the system memory 1200 having a small capacity, and the available storage area of ​​the system memory 1200 can be used to process other operations.

[0172] When the function call information is not retained, the information of the arguments or parameters may not be retained, and the system memory 1200 may be used more efficiently. In particular, even if the electronic system 1000 implemented with a mobile or portable device includes a system memory 1200 with a small capacity, sufficient performance information associated with many events may be collected.

[0173] In addition, for each evolution, it may not be necessary to convert the entire function call and transfer command set to the graphics processor device 1400. Therefore, it is possible to prevent the efficiency of performance analysis from being reduced.

[0174] In addition, since the command set is generated only once and provided only once to the graphics processor device 1400, the commands can be scheduled and processed identically for each evolution. That is, replay can be implemented based on consistent commands and data, and the consistency of commands and data used for replay can be improved. Therefore, correlation can be easily performed between count values, and correlation between count values ​​can be accurately established. Command set-based replay can be advantageously used for next-generation APIs in a command queue manner, such as the Vulkan API.

[0175] exist Figures 12 to 15In some example embodiments, the number of times each replay is repeated may be determined based on the number of registers and the number of command sets. In some example embodiments, the analysis configuration and / or the counter configuration may include information associated with the number of times each replay is repeated according to the determination of the user 10 or the electronic system 1000. In some cases, the user 10 or the electronic system 1000 may forcibly stop or terminate the replay.

[0176] Fig.19 and 20 It is used to describe Figures 12 to 15 A conceptual diagram of an example relationship between a command set and counter configuration values ​​is shown in FIG.

[0177] As described above, a command set may be associated with a counter configuration. When requesting performance analysis, the scheduler 1410 may receive the counter configuration information along with the command set.

[0178] See also Fig.19 , command sets “A”, “B”, and “C” may be provided, and the counter configuration information may include counter configuration values ​​“A”, “B”, and “C”. The counter configuration values ​​“A”, “B”, and “C” may correspond to the command sets “A”, “B”, and “C”, respectively, and may refer to the configurations used to set performance counters 1451 to 1459 associated with processing operations directed by the command sets “A”, “B”, and “C”.

[0179] Counter configuration values ​​"A", "B", and "C" may be provided to differently set the configurations of performance counters 1451 to 1459. For example, the configurations of performance counters 1451 to 1459 set by counter configuration value "A" may be different from the configurations of performance counters 1451 to 1459 set by counter configuration value "B".

[0180] In this case, the configuration of the performance counters 1451 to 1459 associated with the processing operation directed by the command set “A” may be different from the configuration of the performance counters 1451 to 1459 associated with the processing operation directed by the command set “B”. Therefore, the number of times the events of interest that occur for the operations directed by the command sets “A”, “B”, and “C” may be counted under different setting configurations of the performance counters 1451 to 1459.

[0181] For example, when command sets "A", "B", and "C" are associated with graphics processing, the operations directed by command sets "A", "B", and "C" may have different characteristics or may require different operating conditions. For example, when the image to be displayed on the display device 1405 changes significantly, command sets "A", "B", and "C" may have different conditions for various factors such as the number of "DrawCall" commands, color, image size, etc. In this case, if Fig.19 As shown, different counter configuration values ​​"A", "B" and "C" may be provided.

[0182] against Figures 12 to 15 In an example embodiment, the operation directed by the command set "A" may be repeated. For each repetition, the command set "A" may correspond to the counter configuration value of the event set associated with each repetition. For example, when there are different P event sets, the operation directed by the command set "A" may be repeated P times for the corresponding repetition under different setting configurations of the performance counters 1451 to 1459.

[0183] See also Fig. 20 , command sets "A1", "A2", "B1", "B2" and "B3" may be provided, and the counter configuration information may include counter configuration values ​​"A" and "B". Fig. 20 In the example shown in FIG. 1 , one counter configuration value may correspond to multiple command sets.

[0184] For example, the counter configuration value "A" may correspond to the command sets "A1" and "A2" and may be referenced to set the configuration of the performance counters 1451 to 1459 associated with processing operations directed by the command sets "A1" and "A2". The counter configuration value "B" may correspond to the command sets "B1", "B2", and "B3" and may be referenced to set the configuration of the performance counters 1451 to 1459 associated with processing operations directed by the command sets "B1", "B2", and "B3".

[0185] The counter configuration values ​​"A" and "B" may be provided to differently set the configurations of the performance counters 1451 to 1459. Meanwhile, since the command sets "A1" and "A2" correspond to one counter configuration value "A", the configurations of the performance counters 1451 to 1459 associated with processing operations directed by the command set "A1" may be the same as the configurations of the performance counters 1451 to 1459 associated with processing operations directed by the command set "A2".

[0186] Therefore, the number of times that events of interest occur for operations directed by command sets "A1" and "A2" can be counted under the same configuration of performance counters 1451 to 1459 set by one counter configuration value "A". Similarly, the number of times that events of interest occur for operations directed by command sets "B1", "B2", and "B3" can be counted under the same configuration of performance counters 1451 to 1459 set by one counter configuration value "B".

[0187] For example, when the command sets “A1”, “A2”, “B1”, “B2”, and “B3” are associated with simple operation processing other than graphic processing, it is likely that the operations directed by the command sets “A1”, “A2”, “B1”, “B2”, and “B3” have the same characteristics or similar characteristics, or require the same operating conditions or similar operating conditions. In this case, in order to improve the efficiency of the operation processing and the efficiency of the bus bandwidth, one counter configuration value may be provided to correspond to a plurality of command sets.

[0188] For example, command sets requiring the same condition or similar conditions may be grouped to correspond to one counter configuration value. The command sets grouped to correspond to one counter configuration value may be predetermined according to the intention of the user 10 or the operation policy of the electronic system 1000. Alternatively, the command sets grouped to correspond to one counter configuration value may be dynamically changed depending on various factors such as context trends, data types, etc.

[0189] against Figures 12 to 15 In an example embodiment, the operations directed by the command sets "A1" and "A2" may be repeated. For each repetition, the command sets "A1" and "A2" may correspond to the counter configuration values ​​of the event sets associated with each repetition.

[0190] For example, when there are different P event sets, the operations directed by command sets "A1" and "A2" may be repeated P times for corresponding repetitions under configurations of different settings of performance counters 1451 to 1459. However, when the command of command set "A2" is processed after the repetition command of command set "A1" is completed, the configurations of performance counters 1451 to 1459 may be maintained without change.

[0191] The above description is intended to provide example configurations and operations for implementing the disclosed embodiments. In addition to the above example embodiments, the scope and spirit of the present invention may include implementations obtained by simply changing or modifying the above example embodiments. In addition, the scope and spirit of the present invention include implementations implemented by easily changing or modifying the above example embodiments later.

Claims

1. A processor device, comprising: a scheduler configured to schedule a first command of a first command set and a second command of a second command set so that the processor circuit processes a first operation directed by the first command set and a second operation directed by the second command set; a performance counter configured to count a number of occurrences of events of interest while the processor circuit is processing the first operation and the second operation, wherein each number corresponds to one of the events of interest; and a register configured to store a count value corresponding to the number of counts, wherein, when the number of events of interest is greater than the number of registers, the first operation is repeatedly processed so that the number of all events of interest is counted for the first operation, and the second operation is processed after the number of all events of interest is counted for the first operation, and The event of interest includes at least one of a cache miss, a bus conflict, a process idle state, a vertex count, or a primitive count.

2. The processor device of claim 1, wherein: A first set of commands and a second set of commands are received at a scheduler based on first and second function calls generated from execution of an application, respectively.

3. The processor device according to claim 1, The scheduler receives each of the first command set and the second command set from the driver once.

4. The processor device according to claim 1, in, Each of the first command set and the second command set is configured in a grouping unit or a batch unit, and The first commands included in the first command set are processed continuously in a first processing interval, and the second commands included in the second command set are processed continuously in a second processing interval.

5. The processor device of claim 1, wherein: After counting the number of all events of interest for the first operation, the second operation is repeatedly processed so that the number of all events of interest for the second operation is counted. 6 . The processor device of claim 5 , wherein the number of times the first operation is counted with respect to each event of interest is added to the number of times the second operation is counted with respect to each corresponding event of interest.

7. A processor device comprising: A scheduler configured to schedule a first command of a first command set and a second command of a second command set; and a performance counter configured to count a number of events of interest that occur with respect to processing a first operation directed by a first set of commands and a second operation directed by a second set of commands, wherein each number corresponds to one of the events of interest, wherein the first command in the first command set is repeatedly scheduled so that the number of all events of interest is counted for the first operation, wherein after counting the number of all events of interest for the first operation, a second command in the second command set is scheduled, and The event of interest includes at least one of a cache miss, a bus conflict, a process idle state, a vertex count, or a primitive count.

8. The processor device of claim 7, wherein the scheduler is further configured to set the configuration of the performance counter so that the performance counter counts the number of events of interest.

9. The processor device of claim 8, wherein: The scheduler is further configured to change a configuration of the performance counter for each repetition of the first command of the first command set.

10. The processor device of claim 8, wherein: After executing the first operation processing, when the number of all events of interest is not completely counted for the first operation, the scheduler is further configured to change the configuration of the performance counter and repeatedly schedule the first command of the first command set so as to count the uncounted events of interest.

11. The processor device of claim 7, wherein: Among the events of interest corresponding to the counted times, a first event of interest corresponding to the number of times counted in the first repetition of the first command of the first command set and a second event of interest corresponding to the number of times counted in the second repetition of the first command of the first command set are different.

12. The processor device of claim 11, further comprising: a register configured to store a count value corresponding to the number of counts, The registers are also configured as: storing a first count value corresponding to a first event of interest in a first repetition, After the first repetition is completed, the first count value is outputted so that the first count value is stored in the buffer memory, and After outputting the first count value, a second count value corresponding to a second event of interest in a second repetition is stored.

13. The processor device according to claim 12, in, The register is further configured to store a third count value corresponding to the first event of interest in a third repetition of the second command of the second command set, and Wherein, for processing the first operation and the second operation, the sum of the first count value and the third count value is provided.

14. A processor device comprising: processor circuitry configured to process operations directed by each of the plurality of command sets; and a performance counter configured to count a number of occurrences of events of interest while the processor circuit is processing operations directed by each of the plurality of command sets, wherein each number corresponds to one of the events of interest, wherein the operations directed by each of the plurality of command sets are repeatedly processed until the number of all events of interest is counted for the operations directed by each of the plurality of command sets, wherein, after counting the number of all events of interest for a first operation directed by a first command set among the plurality of command sets, a second operation directed by a second command set among the plurality of command sets is processed, and The event of interest includes at least one of a cache miss, a bus conflict, a process idle state, a vertex count, or a primitive count.

15. The processor device of claim 14, further comprising: a scheduler configured to receive a plurality of command sets from the driver and cause the processor circuit to process operations directed by each of the plurality of command sets, The scheduler receives each of the multiple command sets at a time.

16. The processor device of claim 15, wherein: The scheduler is also configured to: When the number of all events of interest has not been completely counted for the first operation, repeatedly scheduling the commands of the first command set so that the first operation directed by the first command set is repeatedly processed, and After counting the number of all events of interest for the first operation, commands of the second command set are scheduled so that the second operation directed by the second command set is processed.

17. The processor device of claim 14, further comprising: The scheduler is configured to set the configuration of the performance counter based on the counter configuration information so that the number of different events of interest is counted for each repetition of the operation directed by each command set of the plurality of command sets.

18. The processor device of claim 17, in, The counter configuration information includes a plurality of counter configuration values ​​provided to differently set the configuration of the performance counter. wherein the plurality of command sets correspond to the plurality of counter configuration values ​​respectively, and For operations directed by multiple command sets, the number of events of interest is counted under different setting configurations of performance counters.

19. The processor device of claim 17, in, The counter configuration information includes the counter configuration value, wherein the plurality of command sets correspond to counter configuration values, and For operations directed by multiple command sets, the number of events of interest is counted under the configuration of a performance counter set by a counter configuration value.

Images