Interface flow controller for data center cooling systems

Abstract

Interface flow controllers for data center cooling systems are disclosed, specifically systems and methods for cooling a data center are disclosed. In at least one embodiment, a first interface flow controller includes a sensor and is associated with a first server tray of a rack, such that the first interface flow controller can receive sensor input and can communicate with a second interface flow controller over a communication link therebetween, where the second interface flow controller can be associated with a coolant distribution unit (CDU) to balance coolant flow to be provided from the CDU to one or more second server trays based in part on changes in coolant flow to the first server tray indicated by such sensor input.

Description

TECHNICAL FIELD

[0001] At least one embodiment pertains to cooling systems, including systems and methods for operating such cooling systems. In at least one embodiment, such cooling systems can be utilized in a data center containing one or more racks or computing servers. BACKGROUND

[0002] Data center cooling systems use fans to circulate air through server components. Certain supercomputers or other high-capacity computers can use water or other cooling systems instead of air cooling systems to draw heat away from server components or racks of a data center to an area outside of the data center. The cooling system can include a chiller within the data center area, which can include an area outside of the data center itself. Further, the area outside of the data center can include a cooling tower or other external heat exchanger that receives heated coolant from the data center and dissipates heat to the environment (or external cooling medium) through forced air or other means. The cooled coolant is recirculated back into the data center. Together, the chiller and cooling tower form a cooling plant. BRIEF DESCRIPTION OF DRAWINGS

[0003] FIG. 1 An example data center cooling system subject to improvements described in at least one embodiment is shown;

[0004] FIG. 2 Server-level features associated with an interface flow controller of a data center cooling system, according to at least one embodiment, are shown;

[0005] FIG. 3 Rack-level features associated with an interface flow controller of a data center cooling system, according to at least one embodiment, are shown;

[0006] FIG. 4 Data center-level features associated with an interface flow controller of a data center cooling system, according to at least one embodiment, are shown;

[0007] FIG. 5 A method associated with a data center cooling system, according to at least one embodiment, is shown; FIGS. 2-4

[0008] FIG. 6A Inference and / or training logic is shown in accordance with at least one embodiment;

[0009] FIG. 6B Inference and / or training logic is shown in accordance with at least one embodiment;

[0010] FIG. 7 ​Training and deployment of neural networks are shown in accordance with at least one embodiment;

[0011] FIG. 8 An example data center system is shown in accordance with at least one embodiment;

[0012] FIG. 9 is a block diagram illustrating a computer system in accordance with at least one embodiment;

[0013] FIG. 10 is a block diagram illustrating a computer system in accordance with at least one embodiment;

[0014] FIG. 11 A computer system is shown in accordance with at least one embodiment;

[0015] FIG. 12 A computer system is shown in accordance with at least one embodiment;

[0016] FIG. 13A A computer system is shown in accordance with at least one embodiment;

[0017] FIG. 13B A computer system is shown in accordance with at least one embodiment;

[0018] FIG. 13C A computer system is shown in accordance with at least one embodiment;

[0019] FIG. 13D A computer system is shown in accordance with at least one embodiment;

[0020] FIG. 13E and FIG. 13F A shared programming model is shown in accordance with at least one embodiment;

[0021] FIG. 14 An exemplary integrated circuit and associated graphics processor are shown in accordance with at least one embodiment;

[0022] FIG. 15A , FIG. 15B An exemplary integrated circuit and associated graphics processor are shown in accordance with at least one embodiment;

[0023] FIG. 16A , FIG. 16B Additional exemplary graphics processor logic is shown in accordance with at least one embodiment;

[0024] FIG. 17 A computer system is shown in accordance with at least one embodiment;

[0025] FIG. 18A A parallel processor is shown in accordance with at least one embodiment;

[0026] FIG. 18B A partition unit is shown in accordance with at least one embodiment;

[0027] FIG. 18C A processing cluster is shown in accordance with at least one embodiment;

[0028] FIG. 18D A graphics multiprocessor is shown in accordance with at least one embodiment;

[0029] FIG. 19 A multi-GPU system is shown in accordance with at least one embodiment;

[0030] FIG. 20 A graphics processor is shown in accordance with at least one embodiment;

[0031] FIG. 21 is a block diagram illustrating a processor micro-architecture for a processor in accordance with at least one embodiment;

[0032] FIG. 22 A deep learning application processor is shown in accordance with at least one embodiment;

[0033] FIG. 23 is a block diagram illustrating an example neuromorphic processor in accordance with at least one embodiment;

[0034] FIG. 24 At least a portion of a graphics processor is shown in accordance with one or more embodiments;

[0035] FIG. 25 At least a portion of a graphics processor is shown in accordance with one or more embodiments;

[0036] FIG. 26 At least a portion of a graphics processor is shown in accordance with one or more embodiments;

[0037] FIG. 27 is a block diagram of a graphics processing engine of a graphics processor in accordance with at least one embodiment;

[0038] FIG. 28 is a block diagram of at least a portion of a graphics processor core in accordance with at least one embodiment;

[0039] FIG. 29A , FIG. 29B Thread execution logic is shown in accordance with at least one embodiment, including an array of processing elements of a graphics processor core.

[0040] FIG. 30 A parallel processing unit (“PPU”) is shown in accordance with at least one embodiment;

[0041] FIG. 31A general processing cluster (“GPC”) is shown in accordance with at least one embodiment;

[0042] FIG. 32 A memory partition unit of a parallel processing unit (“PPU”) is shown in accordance with at least one embodiment;

[0043] FIG. 33 A streaming multiprocessor is shown in accordance with at least one embodiment;

[0044] FIG. 34 is an example dataflow graph of an advanced compute pipeline in accordance with at least one embodiment;

[0045] FIG. 35 is a system diagram of an example system for training, adapting, instantiating, and deploying machine learning models in an advanced compute pipeline in accordance with at least one embodiment;

[0046] FIG. 36A is a dataflow graph of a process for training a machine learning model in accordance with at least one embodiment; and

[0047] FIG. 36B is an example illustration of a client-server architecture that leverages a pre-trained annotation model to augment an annotation tool in accordance with at least one embodiment. DETAILED DESCRIPTION

[0048] In at least one embodiment, an exemplary data center 100 as shown in FIG. 1 is subjected to the improved cooling systems described herein. In at least one embodiment, numerous specific details are set forth in order to provide a thorough understanding of the concepts herein but it can be practiced without one or more of these specific details in at least one embodiment. In at least one embodiment, a data center cooling system can respond to sudden high heat demands caused by changing computational loads in today’s computing components. In at least one embodiment, since these demands are subjected to changes or tend to a range of minimum to maximum values of different cooling demands, appropriate cooling systems must be used to meet these demands in an economical way. In at least one embodiment, for medium to high cooling demands, a liquid cooling system can be used. In at least one embodiment, high cooling demands are economically met by local immersion cooling. In at least one embodiment, these different cooling demands also reflect different thermal characteristics of a data center. In at least one embodiment, heat generated from these components, servers, and racks is collectively referred to as thermal characteristics or cooling demands since cooling demands must fully address thermal characteristics.

[0049] In at least one embodiment, a data center liquid cooling system is disclosed. In at least one embodiment, the data center cooling system addresses thermal signatures in associated computing or data center equipment, such as in a graphics processing unit (GPU), in a switch, in a dual in-line memory module (DIMM), or in a central processing unit (CPU). In at least one embodiment, these components can be referred to herein as high heat density computing components. Further, in at least one embodiment, the associated computing or data center equipment can be a processing card having one or more GPUs, switches, or CPUs thereon. In at least one embodiment, each of the GPUs, switches, and CPUs can be a heat generating feature of the computing equipment. In at least one embodiment, a GPU, CPU, or switch can have one or more cores, and each core can be a heat generating feature.

[0050] In at least one embodiment, an interfacing flow controller is provided for a data center cooling system. In at least one embodiment, a first interfacing flow controller of such an interfacing flow controller includes a sensor and is associated with a first server tray of a rack. In at least one embodiment, this enables the first interfacing flow controller to receive sensor input and to communicate with a second interfacing flow controller that is associated with a coolant distribution unit (CDU). In at least one embodiment, such communication is over a communication line between the first interfacing flow controller and the second interfacing flow controller. In at least one embodiment, such at least one processor is within the first interfacing flow controller, and a second processor of the second interfacing flow controller receives and processes the communication. In at least one embodiment, such a communication line is wired or wireless and follows a wireless or wired communication protocol. In at least one embodiment, the second interfacing flow controller can cause a balancing of coolant flow from the CDU to one or more second server trays based in part on a change in coolant flow to the first server tray as indicated by such sensor input.

[0051] In at least one embodiment, an interfacing flow controller can address issues associated with standard flow controllers and sensors that are distinct components and are controlled by a central control system. In at least one embodiment, such a central control system takes input from the sensors and can cause action in any of the provided standard flow controllers. However, in at least one embodiment, this process can delay response times associated with changes in determined coolant flow, for example, a disruption in flow of coolant flow at a standard flow controller in a data center cooling system having multiple such standard flow controllers ready to provide a determined coolant flow. In at least one embodiment, a rate of flow or flow of coolant can be expressed in terms of a coolant flow.

[0052] In at least one embodiment, a group of six servers in a rack can be associated with 60 LPM (liters per minute) or equivalent GPM (gallons per minute) of provided auxiliary coolant from a CDU. In at least one embodiment, when one or more of such six servers is removed, a corresponding or relative change in coolant flow is required to maintain economical cooling of the data center cooling system. In at least one embodiment, as soon as a server is disconnected from a corresponding inlet interface flow controller, such as an inlet interface flow controller including a sensor and a processor, a sensor input can be provided to an outlet interface flow controller associated with the CDU. In at least one embodiment, in response, the outlet interface flow controller can cause a reduction in coolant flow rate or flow to the rack or row of racks. In at least one embodiment, since interface flow controllers can communicate directly or via other interface flow controllers, for example, using a flow-through protocol of addressed packets to pass sensor inputs from one flow controller to the next until it reaches a destination flow controller, a response to a disconnect in one server tray is nearly instantaneous.

[0053] In at least one embodiment, one benefit of this solution is that it allows interface flow controllers to interface with each other without a central control system. In at least one embodiment, interface flow controllers can include a sensor with a processor, an actuator (or pump), and with a communication ability to direct or serial communication between such interface flow controllers. In at least one embodiment, the ability of interface flow controllers referred to throughout this document to communicate with each other directly or through other interface flow controllers is through instructions processed by the processors and communicated by such communication ability.

[0054] In at least one embodiment, the processors of at least first and second interface flow controllers that are the target of the communication are able to package and communicate data through such communication ability, where such data can include instructions and acknowledgements. However, in at least one embodiment, a third interface flow controller that performs a pass-through role can not engage its processor, but simply use the communication ability to pass through such target packets. However, in at least one embodiment, the processor of such third interface flow controller can be set to a standby state to conserve power, while the communication ability therein enables pass-through communication that can be wired or wireless communication over a provided communication line that can be a wired or wireless communication line.

[0055] In at least one embodiment, a server tray can be removed from a rack. In at least one embodiment, such a server tray or associated interface flow controller of a rack informs an outlet interface flow controller of a CDU. In at least one embodiment, an outlet interface flow controller of a CDU is located in close proximity to an outlet of a CDU or is located remotely from a CDU, for example, at a row manifold or other manifold. In at least one embodiment, such an outlet interface flow controller balances coolant flow so that any remaining server trays receive a determined coolant flow (intended coolant flow prior to removal of one server tray) regardless of interference caused to an associated interface flow controller by such removal.

[0056] In at least one embodiment, fluid and flow properties can control how a liquid-cooled data center utilizes its cooling distribution units (CDUs), which can also apply to heat exchangers (HXs). In at least one embodiment, in a heterogeneous data center application, where there are many different information technology (IT) devices, such as servers, switches, and other devices utilizing CPUs, GPUs, and switches, cooling of these devices can need to be supported by one or more CDUs, as fluid and flow dynamics are different in each IT device. In at least one embodiment, such IT devices, particularly in a test environment, can be in their assigned locations in a data center rack at any point in time and multiple occurrences or non-occurrences during a test. In at least one embodiment, when one or more other servers are associated with at least one CDU, it can be challenging to continuously adjust cooling needs of existing servers upon removal of one or more other servers.

[0057] In at least one embodiment, an interface flow controller can include a fluid pump or a fluid and flow control valve with actuator support. In at least one embodiment, such an interface flow controller has the ability to control coolant flow therethrough. In at least one embodiment, an interface flow controller can include a pump or a valve and can include a processor and sensors. In at least one embodiment, sensors are a collective reference to one or more sensors in a sensor package. In at least one embodiment, sensors herein can provide information associated with key fluid and flow properties, such as fluid concentration, electrical conductivity, pH, flow rate, flow volume, temperature, and pressure of a coolant. In at least one embodiment, a processor associated with sensors can determine such fluid and flow properties from received such information. In at least one embodiment, such an interface flow controller can be deployed using a single or multiple CDUs for each rack in a data center application to liquid cool IT devices on each of a plurality of racks having servers therein.

[0058] In at least one embodiment, interface flow controllers can thus include smart devices deployed for each server rack and CDU. In at least one embodiment, such interface flow controllers are disposed at least at the intake of a server tray. In at least one embodiment, such interface flow controllers are disposed at least at the outlet of a CDU, and proximate or remote from such outlet. In at least one embodiment, an interface flow controller of a server tray intake is communicatively coupled with another interface flow controller of a CDU outlet. In at least one embodiment, depending on the flow rate or flow from one interface flow controller, control of coolant flow is caused by input from the other interface flow controller.

[0059] In at least one embodiment, other aspects of coolant flow can be monitored, such as the temperature, pressure, pH, or concentration of secondary coolant flowing in each server of a rack. In at least one embodiment, a network of interface flow controllers can coordinate together using a smart flow control algorithm that allows for passing communication through a series of interface flow controllers, and allows for targeted communication between interface flow controllers. In at least one embodiment, such an algorithm includes a startup procedure that is characterized by handshaking with all connected interface flow controllers, exchanging configuration for all connected interface flow controllers, and priority indication communication between all connected interface flow controllers. In at least one embodiment, such an algorithm enables one interface flow controller to designate a recipient interface flow controller, either directly or using passing from one interface flow controller to a series of interface flow controllers to the recipient interface flow controller.

[0060] In at least one embodiment, when such interface flow controllers are deployed, they can control upstream interface flow controllers (such as pumps or valves associated with heat exchangers or CDUs) to cause optimal operation of the entire interface flow controller network. In at least one embodiment, this feature enables dynamic control of coolant flow under transient conditions, including the presence or absence of IT equipment in one or more racks, without requiring manual intervention at least of the CDU to adjust coolant flow when a server tray is removed. In at least one embodiment, this ability to precisely measure and control fluid properties creates a better means of fluid chemistry control associated with the performance of CDUs in data center applications.

[0061] In at least one embodiment, the ability to precisely measure and control fluid properties creates a better means of fluid chemistry control associated with the performance of CDUs in data center applications. FIG. 1An exemplary data center 100 is shown, which has undergone improvements in cooling described herein. In at least one embodiment, the data center 100 can be one or more rooms 102 with racks 110 and ancillary equipment to house one or more servers on one or more server trays. In at least one embodiment, the data center 100 is supported by a cooling tower 104 located outside of the data center 100. In at least one embodiment, the cooling tower 104 dissipates heat from within the data center 100 by acting on a primary cooling loop 106. In at least one embodiment, a cooling distribution unit (CDU) 112 is used between the primary cooling loop 106 and a secondary or auxiliary cooling loop 108 to enable extraction of heat from the secondary or auxiliary cooling loop 108 to the primary cooling loop 106. In at least one embodiment, in one aspect, the auxiliary cooling loop 108 can tap into different plumbing equipment that enters the server trays as needed. In at least one embodiment, the loops 106, 108 are shown as line graphs, but one of ordinary skill will recognize that one or more plumbing equipment features can be used. In at least one embodiment, flexible polyvinyl chloride (PVC) tubing can be used with associated plumbing equipment to move fluid along each provided loop 106; 108. In at least one embodiment, one or more coolant pumps can be used to maintain a pressure differential within the coolant loops 106, 108 to enable movement of coolant according to temperature sensors in different locations, including in the room, in one or more racks 110, and / or in server enclosures or server trays within one or more racks 110.

[0062] In at least one embodiment, the coolant in the primary cooling loop 106 and the auxiliary cooling loop 108 can be at least water and an additive. In at least one embodiment, the additive can be ethylene glycol or propylene glycol. In operation, in at least one embodiment, each of the primary cooling loop and the auxiliary cooling loop can have their own coolant. In at least one embodiment, the coolant in the auxiliary cooling loop can be specific to the requirements of the server trays or components in the associated racks 110. In at least one embodiment, the CDU 112 is capable of sophisticated control of the coolant within the provided coolant loops 106, 108 independently or simultaneously. In at least one embodiment, the CDU can be adapted to control the flow rate of the coolant such that the coolant is appropriately distributed to extract heat generated within the associated racks 110. In at least one embodiment, more flexible tubing 114 is provided from the auxiliary cooling loop 108 to enter each server tray to provide coolant to the electrical and / or computing components therein.

[0063] In at least one embodiment, tubing 118 forming part of secondary cooling loop 108 can be referred to as a room manifold. Separately, in at least one embodiment, additional tubing 116 can extend from row manifold tubing 118 and can also be part of secondary cooling loop 108, but can be referred to as a row manifold. In at least one embodiment, coolant tubing 114 enters a rack as part of secondary cooling loop 108, but can be referred to as a rack cooling manifold within one or more racks. In at least one embodiment, piping equipment including coolant manifolds 118, 116, and 114 of secondary cooling loop 108 can be improved upon by at least one embodiment herein. In at least one embodiment, chillers 120 can be provided in a primary cooling loop within data center 102 to support cooling prior to a cooling tower. In at least one embodiment, for the present disclosure, an additional cooling loop that can be in a primary control loop and provide cooling outside of racks and outside of secondary cooling loop can be with the primary cooling loop and different from the secondary cooling loop.

[0064] In at least one embodiment, in operation, heat generated within server trays of provided racks 110 can be transferred via flexible tubing of row manifold 114 of secondary cooling loop 108 to coolant exiting one or more racks 110. In at least one embodiment, second coolant from CDU 112 for cooling provided racks 110 (in secondary cooling loop 108) moves via provided tubing toward one or more racks 110. In at least one embodiment, second coolant from CDU 112 passes from one side of room manifold having tubing 118 via row manifold 116 to one side of racks 110 and via different tubing 114 through one side of server trays. In at least one embodiment, used or returning second coolant (or exiting second coolant carrying heat from computing components) exits from another side of server trays (such as entering a left side of a rack after circulating through a server tray or through components on a server tray and exiting a right side of a rack for a server tray). In at least one embodiment, used second coolant exiting server trays or racks 110 comes out of a different side (such as an exit side) of tubing 114 and moves to a parallel but also an exit side of row manifold 116. In at least one embodiment, used second coolant moves from row manifold 116 in a parallel portion of room manifold 118 and travels toward CDU 112 in an opposite direction from incoming second coolant (which can also be newer second coolant).

[0065] In at least one embodiment, the used second coolant exchanges heat with the main coolant in the main cooling circuit 106 via CDU 112. In at least one embodiment, the used second coolant can be refreshed (e.g., relatively cooled when compared to the temperature of the used second coolant stage) and prepared to be circulated back to one or more computing components via the second cooling circuit 108. In at least one embodiment, various flow and temperature control features in CDU 112 are capable of controlling the heat exchanged from the used second coolant or the flow of the second coolant in and out of CDU 112. In at least one embodiment, CDU 112 is also capable of controlling the flow of the main coolant in the main cooling circuit 106.

[0066] In at least one embodiment, such as FIG. 2 The server-level feature 200 shown may be associated with an interface traffic controller. In at least one embodiment, the server-level feature 200 includes a server tray or enclosure 202. In at least one embodiment, the server tray or enclosure 202 includes a server manifold 204 intermediately coupled between a provided cold plate 210A-D of the server tray or enclosure 202 and a rack manifold of the rack hosting the server tray or enclosure 202. In at least one embodiment, the server tray or enclosure 202 includes one or more cold plates 210A-D associated with one or more computing or data center components or devices 220A-D. In at least one embodiment, the one or more cold plates 210A-D may be dual-coolant cold plates having a first feature 264, such as a first fin or tube, for cooling with a first coolant, or using a second feature 270A, such as a second fin or tube, for cooling with a second coolant. In at least one embodiment, a first CDU provides the first coolant, and a second CDU provides the second coolant.

[0067] In at least one embodiment, one or more server level cooling loops 214A, 214B can be provided between server manifold 204 and one or more cold plates 210A-D for dual coolant cold plates. In at least one embodiment, each server level cooling loop 214A, 214B includes an inlet line 210 and an outlet line 212. In at least one embodiment, when there are cold plates 210A, 210B in series configuration, an intermediate line 216 can be provided. However, in at least one embodiment, for a standard flow controller 280 can be associated with a provided line 276A that can be established between passages (shown in dashed lines) within a dual manifold 204 that is adapted to pass a first coolant through different provided lines 206A, B and a second coolant through a provided line associated with these provided lines 208A, B. In at least one embodiment, there can be separate server cooling manifolds for a first coolant and a second coolant, each of different chemical composition.

[0068] In at least one embodiment, one or more cold plates 210A-D can be either dual coolant only cold plates or single coolant only cold plates. In at least one embodiment, one or more cold plates 210A-D, when adapted for dual coolant purposes, can support a first secondary coolant for a first secondary cooling loop with a first CDU and a second secondary coolant for circulation from a second CDU instead of a different port and passage for the first secondary coolant. In at least one embodiment, a fluid for cooling, such as a first secondary coolant, can be provided to server manifold 204 via provided inlets and outlets 206A, 206B. In at least one embodiment, a second secondary coolant for cooling can be provided to server manifold 204 via provided inlets and outlets 208A, 208B.

[0069] In at least one embodiment, all such manifolds, lines or loops can be terminated at server inlets and server outlets on an inlet side using at least an interface flow controller 278 and on an outlet side using an interface or standard flow controller. In at least one embodiment, FIG. 2 Inlet and outlet sides of cold plates 210A-D provided in FIG. 2 can each have a standard flow controller associated therewith, e.g., without a processor and sensors and ability to communicate with an interface flow controller via a communication line.

[0070] In at least one embodiment, for a CDU, an interface flow controller can be provided on an outlet side, and a standard flow controller can be provided on an inlet side. In at least one embodiment, such interface flow controllers and standard flow controllers have mechanical coupling features and electrical coupling features. In at least one embodiment, in addition to pump or actuator supported valves, electrical coupling features in an interface flow controller include at least a processor, sensors, communication capabilities. In at least one embodiment, at least one processor within at least an interface flow controller enables control aspects for other interface flow controllers. In at least one embodiment, a standard flow controller can have electrically pump or actuator supported valves.

[0071] In at least one embodiment, server tray 202 is an immersion cooled server tray that can be flooded with a fluid. In at least one embodiment, a fluid for an immersion cooled server tray can be a dielectric engineering fluid that can be used in an immersion cooled server. In at least one embodiment, an engineering fluid can be cooled using a secondary coolant. In at least one embodiment, a secondary coolant can be used to cool an engineering fluid when a primary cooling loop associated with a first CDU and a first secondary cooling loop circulating a first secondary coolant has failed or is failing. Thus, in at least one embodiment, at least one cold plate has ports from interface flow controllers of different CDUs for a first secondary cooling loop and for a second secondary cooling loop. In at least one embodiment, such a cold plate can support a first coolant or a second coolant that can be activated in the event of a failure in a primary cooling loop supporting a first coolant.

[0072] In at least one embodiment, at least one dual-cooled cold plate 210B; 250 can be configured to work with a conventional cold plate 210A, C, D that supports only one coolant. In at least one embodiment, a three-dimensional (3D) exploded illustration (cold plate 250) provides internal details of at least some features that can be included in components used in a dual-cooled cold plate or a conventional cold plate. In at least one embodiment, a torn apart illustration of cold plate 250 shows microchannels 270, 270A. In at least one embodiment, different second sections can be disposed side-by-side with first sections. In at least one embodiment, a tube 264 can be disposed in one or more sections instead of microchannels. In at least one embodiment, a dual-coolant enabled cold plate can have a set of evaporator coils 264 without microchannels 270, 270A.

[0073] In at least one embodiment, dual-cooled cold plate 250 has different paths 264, 270 for an auxiliary coolant for an auxiliary cooling loop and for a local coolant for a local cooling loop. In at least one embodiment, a local cooling loop can include a heat exchanger for providing temporary relief until any issues with an auxiliary cooling loop associated with a primary cooling loop are resolved. In at least one embodiment, in the case of an immersion-cooled server, a fluid that can be a dielectric engineering fluid can be suitable for both cold plate applications and immersion-cooled server tray applications. In at least one embodiment, some microchannels 270 are paths provided by fins 270A or other such aspects that are elevated internally and perpendicular to a base of a cold plate segment with a gap therebetween for coolant or fluid flow. In at least one embodiment, some microchannels 270, 270A are fluid passageways in different cold plate segments of cold plate 250.

[0074] In at least one embodiment, a reference to a cold plate along with its dual-cooling features can imply a reference to a cold plate that can support at least two types of cooling loops unless otherwise specified. In at least one embodiment, both types of cold plates receive at least an auxiliary coolant for cooling, but one type can support an auxiliary cooling loop or a local cooling loop from a backup CDU or other local coolant source such as a HX. In at least one embodiment, a standard coolant such as facility water can be used for an auxiliary cooling loop or a local cooling loop.

[0075] In at least one embodiment, a fluid or local coolant can only support cold plate use, can not be usable for immersion cooling. In at least one embodiment, each type of cold plate receives a fluid from an interface flow controller that can be associated with different auxiliary or local coolants from a corresponding local cooling loop or other cooling loops that interface with one or more primary cooling loops. In at least one embodiment, in the case of different fluids (e.g., a first auxiliary coolant and a second auxiliary coolant or local coolant) being used in a data center cooling system, then an auxiliary or local cooling loop can be suitable for a dual-cooled cold plate. In at least one embodiment, an auxiliary coolant or local coolant can be supported by an interface flow controller such that different passageways can be used for each of the different auxiliary coolants or local coolants.

[0076] In at least one embodiment, dual-cooled cold plate 250 is adapted to receive two types of fluid (such as auxiliary coolant and local coolant) and to keep the two types of fluid distinct from one another via their different ports 252, 272; 268, 262 and their different paths 264, 270, e.g., by different sections separated by gaskets and plates (e.g., in a gasketed cold plate). In at least one embodiment, fluid lines 256, 258, 266, 274 are associated with such ports 225, 262, 268, 272 via respective standard flow controllers. In at least one embodiment, each different path is a cooling or flow path. In at least one embodiment, fluid (e.g., local coolant or auxiliary coolant) from a local coolant source and an auxiliary coolant source (e.g., a CDU or HX) can be provided simultaneously to address different cooling needs. In at least one embodiment, different ports and paths can support different sources that can be provided to address higher cooling needs from an associated computing device (than can be addressed by a single coolant source).

[0077] In at least one embodiment, dual-cooled cold plate 250 includes ports 252, 272 for receiving a first auxiliary coolant into cold plate 250 to enable such first auxiliary coolant to pass through tube or coil 264 and to enable such first auxiliary coolant to pass out of cold plate 250. In at least one embodiment, dual-cooled cold plate 250 includes ports 268, 262 for receiving a second auxiliary coolant into cold plate 250 and passing local coolant or auxiliary coolant out of cold plate 250. In at least one embodiment, provided ports 252, 272 can have valve caps 254, 260 that can be oriented and pressure-controlled to enable auxiliary coolant or local coolant to flow through cold plate 250.

[0078] In at least one embodiment, provided valve caps 254, 260 are mechanical features of standard flow controllers that also have corresponding electronic features. In at least one embodiment, electronic features of interface flow controller 278 that are different from standard flow controller 280 include at least one processor to execute instructions stored in associated memory to control another interface flow controller (e.g., an interface flow controller associated with a CDU) based in part on input from sensors within interface flow controller 278 or to cause the at least one processor to control mechanical features within interface flow controller based in part on input from sensors within another interface flow controller and that provide an indication.

[0079] In at least one embodiment, each valve can be actuated by an electronic feature of an associated flow controller, whether a standard flow controller or an interface flow controller. In at least one embodiment, the electronic and mechanical features of a provided flow controller are integrated. In at least one embodiment, the electronic and mechanical features of a provided flow controller 278; 280 are physically distinct. In at least one embodiment, reference to a provided flow controller 278; 280 can be reference to one or more of the provided electronic and mechanical features or a combination thereof, but at least reference to features that enable control of coolant or fluid flow through each cold plate or immersed server tray or tank.

[0080] In at least one embodiment, the electronic features of a provided interface flow controller receive control signals and assert control over mechanical features. In at least one embodiment, the electronic features of a provided flow controller 278; 280 can be actuators or other electronic components of other electro-mechanical features. In at least one embodiment, a flow pump can function as an interface flow controller if it also includes a processor and sensors to perform functions associated therewith; but otherwise, a provided flow controller is a standard flow controller if there is no processor and sensors. In at least one embodiment, an impeller, piston, or bellows can be a mechanical feature, and an electric motor and circuitry form the electronic features of a provided flow controller 278; 280. In at least one embodiment, the circuitry of an interface flow controller 278 can include a processor, memory, switches, sensors, and other components that collectively form the electronic features of a provided interface flow controller, which is distinct from a standard flow controller that has actuation and pump features or separate valve features.

[0081] In at least one embodiment, certain provided ports 252, 262, 272, 268 of a provided flow controller 280 are adapted to allow immersion fluid in or allow immersion fluid out. In at least one embodiment, a provided flow controller 280 can be associated with fluid lines 276A, 276B (also 256, 274) that enable first or second secondary coolant to enter and exit a cold plate 210B, 210D. In at least one embodiment, other provided flow controllers can be similarly associated with coolant lines 210, 216, 212 (also 266, 258) to enable secondary coolant to enter and exit a cold plate 210B, 210D.

[0082] In at least one embodiment, the secondary coolant enters the provided fluid lines 276A, B via dedicated inlet and outlet lines 208A, B. In at least one embodiment, the server manifold 204 is adapted to have passages (shown in dashed or broken lines) therein to support different paths to different fluid lines 276A, B (also 256, 274) and any remaining loops 214A, B associated with the secondary coolant inlet and outlet lines 206A, B.

[0083] In at least one embodiment, multiple manifolds 204 can be provided to support interface flow controllers 278 for different secondary coolants located remote from the server inlets 206A; 208A. In at least one embodiment, such interface flow controllers 278 are still considered inlet interface flow controllers in that they are capable of sending information to outlet interface flow controllers associated with a CDU to cause balancing of coolant flow as a result of changes at one or more server level interface flow controllers. Thus, in at least one embodiment, such interface flow controllers 278 can be at the inlets 206A of the server cooling manifolds 204 or can be at the inlets 206A of the server trays 202. In at least one embodiment, there can be multiple manifolds to different support the entry and exit of secondary coolants for each interface flow controller. In at least one embodiment, interface flow controllers are used singularly without a secondary cooling loop and CDU, such as by a local coolant associated with an HX.

[0084] In at least one embodiment, FIG. 3 A rack level feature 300 associated with an interface flow controller for a data center cooling system is shown. In at least one embodiment, such a rack level feature 300 includes one or more racks 302 in one or more rows (e.g., row A 302A and row B 302B). In at least one embodiment, each row 302A, B can be associated with its own cooling manifold 350 associated with a secondary coolant for a cold plate that is a single coolant cold plate or a dual coolant cold plate.

[0085] In at least one embodiment, a data center cooling system, including a first interface flow controller 360 for each server tray 308; 308A-N; 352. In at least one embodiment, as shown, the first interface flow controller 360 is proximate to an entry or inlet of the server tray 308; 352 to feed a cold plate 326 or to feed an HX for an immersion cooled server 352 with a secondary coolant, as FIG. 2The first interface flow controller 360 is shown in close proximity to the server tray 308; 352. However, in at least one embodiment, the first interface flow controller 360 can be further away from the server tray 308, but within the rack 302, for example, at a location at or adjacent to the inlet of the intake rack manifold 314A. In at least one embodiment, the first interface flow controller 360 is located in close proximity to the server tray 308; 352 or adjacent to the intake rack manifold 314A, but maintains its role, which is to control the inlet or intake of coolant into the first server tray 308. In at least one embodiment, the role of the first interface flow controller 360 is to control the flow of coolant into at least one server tray 308; 352.

[0086] In at least one embodiment, the first interface flow controller 360 includes a sensor 360A. In at least one embodiment, such a sensor 360A can be a package of sensors or a plurality of sensors, collectively referred to as a sensor. In at least one embodiment, the sensor 360A herein can provide information associated with critical fluid and flow properties, such as fluid concentration, electrical conductivity, pH, flow rate, flow volume, temperature, and pressure of the coolant, to the processor 360E.

[0087] In at least one embodiment, the processor 360E can determine one or more of such critical fluid and flow properties, such as fluid concentration, electrical conductivity, pH, flow rate, flow volume, temperature, and pressure of the coolant, from information provided by the sensor at the input side of such an interface flow controller 360. In at least one embodiment, the interface flow controller 360 can also include one or more valves or pumps 360F with actuators 360D. In at least one embodiment, the actuators adjust the valves or pumps to provide a flow rate or flow volume of coolant flowing therethrough, for example, from the intake 360B to the outlet 360C. In at least one embodiment, the processor 360E can process information from the sensor 360A to determine a fluid or flow property. In at least one embodiment, the processing of such information refers to inferring a measurement from a portion of such received information based on a correlation encoded as an instruction to be executed by the processor 360E.

[0088] In at least one embodiment, a first interface flow controller 360 can be associated with a first server tray 308 of a rack 302. In at least one embodiment, there can be multiple rows 302A, 302B of racks with server trays 308 that include cold plates 326 for at least one computing device 324 therein. In at least one embodiment, the rows of racks 302A, 302B can include submersion-cooled server trays 352 that are supported by coolant that can also be used to cool the cold plates 326. In at least one embodiment, each server tray 308, 352 includes an inlet 316 and an outlet 318, where each such inlet can include an interface flow controller 360. In at least one embodiment, the outlet can include an interface flow controller 360 or a standard flow controller. In at least one embodiment, a standard flow controller follows instructions for adjusting a flow rate or flow set by a first interface flow controller on an inlet side of a server tray 308; 352.

[0089] In at least one embodiment, additional inlet 320 and outlet 322 features can have one or more cold plates 326 to allow a second, secondary coolant or local coolant to enter a server tray 308; 352 that can have dual-cooled cold plates therein. In at least one embodiment, this allows a second, secondary coolant to be provided differently than a first, secondary coolant that is provided through inlet and outlet features to inlet and outlet racks cooling manifolds 314A and 314B, respectively, to inlet and outlet features 316, 318. In at least one embodiment, such a second, secondary coolant or local coolant is provided via other lines 354 that can use a different flow circuit than the first, secondary coolant within the server tray itself, as described in connection with FIG. 2

[0090] In at least one embodiment, a first interface flow controller 360 can receive sensor input, for example, from a sensor 360A. In at least one embodiment, such sensor input is received into a processor 360E. In at least one embodiment, a processor 360E implements communication between a first interface flow controller 360 and a second interface flow controller 356; 370. In at least one embodiment, a second interface flow controller 356; 370 can be associated with a coolant distribution unit (CDU) 330. In at least one embodiment, a second interface flow controller 356; 370 can be located in close proximity to a CDU 330 or remotely located at a remote location, for example, between a rack cooling manifold 350 and a rack 302.

[0091] ​In at least one embodiment, the role of the second interface flow controller 356; 370 at any location is to control flow from the CDU to at least one of the racks 302. In at least one embodiment, sensor input from the first interface flow controller 360 can be received in the processor 360E therein and can be communicated to the second interface flow controller 356; 370 over a communication line 342; 346; 348 between the first interface flow controller 360 and the second interface flow controller 356; 370. In at least one embodiment, the communication line 342; 346; 348 comprises one or more lines therein capable of bidirectional communication between interface flow controllers and between interface flow controllers and standard flow controllers. In at least one embodiment, the second interface flow controller 356; 370 can balance coolant flow provided from the CDU 330 to one or more second server trays 308A-N; 352 based in part on changes to coolant flow to the first server tray 308 as indicated by such sensor input.

[0092] In at least one embodiment, such changes to coolant flow are caused by a disconnection of the first server tray 308. In at least one embodiment, such disconnection is removal of the first server tray 308 from the rack 302. In at least one embodiment, such removal automatically stops secondary coolant flow into the first server tray, but subsequently causes one or more second interface flow controllers 370; 356 to balance coolant from the CDU 330. In at least one embodiment, balancing of coolant flow can be a reduction in coolant flow rate or coolant amount to remaining server trays 308A-N; 352 of the rack 302.

[0093] In at least one embodiment, the outlet communication line 344 can be part of such mentioned communication lines for enabling control of outlet side interface flow controllers if interface flow controllers are used instead of standard flow controllers. In at least one embodiment, this enables inlet and outlet side flow control and amount control of secondary coolant due to changes determined from sensor input of at least one interface flow controller 360.

[0094] Further, in at least one embodiment, any interface flow controller that controls coolant flow from the CDU to any remaining server trays based in part on input from another interface flow controller of the interrupted server tray, which can be referred to as a second interface flow controller, is different from the interface flow controller that provides the input, which can be referred to as a first interface flow controller. In at least one embodiment, the interrupted server tray can be a server tray that is removed or temporarily disconnected. In at least one embodiment, this is to recognize that interface flow controllers at the input of any remaining server trays 308A-N; 352 that are not affected by a change in coolant flow to one server tray can be used to assist in balancing coolant flow achieved for these remaining server trays 308A-N; 352.

[0095] In at least one embodiment, some interface flow controllers 360 at the server level for the remaining server trays 308A-N; 352 can have settings that allow for certain flow rates or volumes to these remaining server trays, and changes from higher level (e.g., at the rack manifold or CDU level) interface flow controllers 356, 370 can only result in changes to coolant flow that are within a threshold of what these server level interface flow controllers 360 receive. In at least one embodiment, this is to make changes in coolant flow for one server tray not require recalibration of server level interface flow controllers 360 of any remaining server trays 308A-N; 352. In at least one embodiment, in this way, a minimum number (e.g., only one) of interface flow controllers 356; 370 can be used to balance coolant flow as a result of changes in coolant flow indicated by at least a first interface flow controller 360.

[0096] In at least one embodiment, a first secondary coolant can be provided from a row cooling manifold 350, through an inlet 310A, through an interface flow controller 356, and through another inlet 310 of a rack 302. In at least one embodiment, the first secondary coolant flows through an inlet rack cooling manifold 314A, through a server tray 308; 308A-N; 352, through a provided outlet, through an outlet rack cooling manifold 314B, through an outlet 312, 312A, and back to the same or a different (e.g., return) row cooling manifold 350. In at least one embodiment, such returned coolant can be sent to a CDU 330 via an inlet 336 thereof to be heat exchanged with a primary coolant prior to recirculation via an outlet 334 of the CDU 330. In at least one embodiment, on an outlet side of the rack, a standard or interface flow controller 340 can be used to ensure that a desired coolant flow balance can be achieved. In at least one embodiment, for example, control of flow rate or flow can be achieved on one side (an inlet side) while the outlet side is fixed at some open position to allow flow through.

[0097] In at least one embodiment, a second secondary or local coolant can be provided from a different source, either directly or through a different row cooling manifold than illustrated. In at least one embodiment, such a second secondary or local coolant is provided through an inlet 310B, through one or more interface flow controllers 356; 340, and through an outlet 312B. In at least one embodiment, such a second secondary or local coolant can use passages within a rack cooling manifold 314A, B to maintain separation from the first secondary coolant. However, in at least one embodiment, if the two coolants have similar chemical and physical properties, then inlets, outlets, interface flow controllers, and cooling manifolds can be shared.

[0098] In at least one embodiment, at least one processor 360E can be associated with a first interface flow controller 360 to enable the first interface flow controller 360 to receive sensor input from a sensor 360A and to enable communication with a second interface flow controller 356; 370 over a communication line 342; 346; 348. In at least one embodiment, at least one processor 360E can determine that a first server tray 308 is disconnected from the first interface flow controller 360 based in part on input from such a sensor. In at least one embodiment, at least one processor 360E can enable a second interface flow controller 356; 370 to cause a balance of coolant flow from a CDU 330 to one or more second server trays 308A-N; 352.

[0099] In at least one embodiment, the data center cooling system can include a first interface flow controller 360 that can be associated with the inlet 316 of the first server tray 308 to cause a change in coolant flow by stopping coolant flow to the first server tray 308. In at least one embodiment, a second interface flow controller 356; 370 can be associated with the outlet 334 of the CDU to balance coolant flow to one or more second server trays 308A-N; 352.

[0100] In at least one embodiment, the sensor 360A can be adapted to provide sensor input to at least one processor 360E of the first interface flow controller 360. In at least one embodiment, such sensor input can be provided to indicate that the first server tray 308 is disconnected from the first interface flow controller 360. In at least one embodiment, such a disconnection is also a disconnection from another interface or standard flow controller 358 at an outlet side of the first server tray 308. In at least one embodiment, the disconnection then effects a change in coolant flow, e.g., by action of the second interface flow controller 356; 370. In at least one embodiment, such a change in coolant flow is a balancing of coolant flow by reducing coolant relative to coolant flow before the disconnection of the first server tray 308.

[0101] In at least one embodiment, other inlets of the remaining server trays 308A-N; 352 can have interface flow controllers that also contribute to balancing of coolant flow, e.g., by supporting a change in coolant flow. However, in at least one embodiment, since only certain server trays can be disconnected, it is beneficial to centrally balance coolant flow from a minimum number of interface flow controllers 356; 370 associated with the CDU, e.g., one of such interface flow controllers 356; 370.

[0102] In at least one embodiment, the data center cooling system is such that the change in coolant flow can be a stopping of coolant flow to the first server tray 308. In at least one embodiment, the stopping of coolant flow can be needed because the first server tray 308 is being disconnected or removed relative to the data center cooling system.

[0103] In at least one embodiment, the data center cooling system herein is such that the at least one processor 360E can determine that the first server tray 308 of the rack 302 is disconnected from the first interface flow controller 360 based in part on sensor input received from the sensor 306A. In at least one embodiment, such a disconnection can cause a change in coolant flow to the remaining server trays 308A-N; 352 of the rack 302 by the at least one second interface flow controller 356; 370.

[0104] In at least one embodiment, a data center cooling system is such that at least one processor 360E can determine a balance of coolant flow to be provided from CDU 330 to one or more second server trays 308A-N; 352. In at least one embodiment, such a balance of coolant flow can be associated with a flow rate or flow volume intended for one or more second server trays 308A-N; 352 prior to a first server tray 308 being disconnected resulting in a change in coolant flow to first server tray 308. In at least one embodiment, if 60 LPM (or equivalent GPM) is provided to 6 server trays, and then one of the server trays is removed, then 50 LPM flow rate can be enabled by a second interface flow controller associated with a CDU for all remaining server trays after the second interface flow controller is notified by a first interface flow controller associated with the removed server tray.

[0105] In at least one embodiment, a second interface flow controller can be adapted to provide coolant flow to a first server tray 308 and secondary server trays 308A-N; 352 at a first flow or flow rate prior to a first server tray 308 being disconnected. In at least one embodiment, such a disconnection can result in a change in coolant flow. In at least one embodiment, a change in coolant flow can be associated with a decrease in first flow or flow rate. In at least one embodiment, such a decrease results in a second flow or flow rate being provided from a second interface flow controller 356; 370 to one or more secondary server trays 308A-N; 352.

[0106] In at least one embodiment, one or more neural networks can receive sensor input from sensors 360A and can be trained to infer a change in coolant flow to a first server tray 308. In at least one embodiment, such one or more neural networks can be trained using prior sensor input and prior coolant flow changes, as discussed with respect to inference and / or training logic 615 of FIG. 6 and its application as discussed herein with reference to other figures. FIG. 6A

[0107] In at least one embodiment, a balance of coolant flow can be provided from a CDU 330 to a rack 302 as a first flow rate or flow volume after a first server tray 308 is disconnected from a first interface flow controller 360. In at least one embodiment, a first flow rate or flow volume can be a relative measure to a second flow rate or flow volume provided prior to a first server tray 308 and first interface flow controller 360 being disconnected. In at least one embodiment, a first flow rate or flow volume can be lower than a second flow rate or flow volume.

[0108] ​In at least one embodiment, processor 360E includes one or more circuits and may be associated with a first interface flow controller 360. In at least one embodiment, processor 360E may receive sensor input from sensor 360A of the first interface flow controller 360. In at least one embodiment, processor 360E may communicate with a second interface flow controller 356; 370, for example, by communicating with processor 370E of such a second interface flow controller 370, which may also have sensor 370A, inlet 370B, outlet 370C, actuator 370F, and valve or pump 370F. In at least one embodiment, communication lines 342; 246; 348 allow such communication between the first interface flow controller 360 and the second interface flow controller 370.

[0109] In at least one embodiment, when multiple server trays 308A-N; 352 are removed, multiple communications occur from the corresponding processors of the respective first interface flow controllers. In at least one embodiment, as a result, a collision and recheck protocol may allow a second interface flow controller 370 to check the status of one or more disconnected first interface flow controllers 360. In at least one embodiment, depending on the result of such a recheck, the second interface flow controller 356; 370 may provide a cumulative reduction in coolant flow to balance the coolant flow so that coolant is supplied only to one of the remaining server trays 308. In at least one embodiment, the second interface flow controller 356; 370 may be associated with a CDU 330 to balance the coolant flow from the CDU 330 to one or more second server trays, in part based on changes in coolant flow to the first server trays as indicated by such sensor inputs from the first interface flow controllers.

[0110] In at least one embodiment, the processor of the interface flow controller can be as follows: FIG. 18A The processor 1800 shown and discussed with respect to the figure. In at least one embodiment, the output of such a processor can be signaled via communication lines 342; 246; 348 to one or more of the first interface flow controller 360 or the second interface flow controller 356; 370 in response to a change in coolant flow indicated by a sensor input from the first interface flow controller 360.

[0111] In at least one embodiment, the processor may receive sensor input from sensor 360A. In at least one embodiment, this sensor input may be used, in part, to determine changes in the coolant flow toward the first server tray 308 based on continuous monitoring of this sensor input performed by the processor 360A.

[0112] In at least one embodiment, one or more neural networks can receive such sensor inputs and can be trained to infer changes in the coolant flow toward the first server tray 308. In at least one embodiment, such one or more neural networks can be trained using previous sensor inputs and previous coolant flow changes, as per [reference to...]. FIG. 6A The inference and training logic within feature 615 is discussed in detail. In at least one embodiment, at least one logic unit 610 is capable of determining changes in the coolant flow to the first server tray 308, in part based on continuous monitoring of such sensor inputs.

[0113] In at least one embodiment, such as FIG. 4 The data center-level feature 400 shown may be associated with an interface flow controller in a data center cooling system. In at least one embodiment, the data center-level feature 400 within data center 402 may include rows of racks 404 for hosting one or more server trays or enclosures; one or more first interface flow controllers 424; one or more flow lines or loops 416, 426, 418 for transferring auxiliary coolant from row cooling manifolds 410 to cold plates and back to row cooling manifolds 410; one or more second interface flow controllers 412B; 432A associated with CDU 406; and a main coolant line 422 associated with cooling facility 408 via one or more standard or interface flow controllers 412A. In at least one embodiment, such second interface flow controllers 412B; 432A may, in part, cause a balance in the coolant flow supplied from CDU 406 to one or more second server trays based on changes in coolant flow to the first server trays as indicated by sensor inputs from one or more first interface flow controllers 424.

[0114] In at least one embodiment, flow paths 416, 418 couple CDU 406 to row manifold 410 via an interface flow controller 412B associated with CDU 406. This interface flow controller 412B receives signals from other interface flow controllers 432A, 424 associated with one or more racks 404 or server trays or enclosures within each such rack 404. In at least one embodiment, such interface flow controllers 412B, 424 communicate directly or via other interface flow controllers 432A using communication line 428. In at least one embodiment, communication line 428 is shown as a wired line, but it represents one or more wireless communication lines, fiber optic communication lines, or insulated copper communication lines between processors of different interface flow controllers.

[0115] In at least one embodiment, such an interface flow controller can be associated with a server tray, a server manifold, a rack, a rack manifold, and a row manifold to control coolant flow required by homogenous and heterogeneous servers. In at least one embodiment, homogenous and heterogeneous servers refer to multiple server trays or racks having similar heat generation (and thus similar cooling requirements) that make them homogenous server trays or racks; and multiple server trays or racks having different heat generation (and thus different cooling requirements) that make them heterogeneous server trays or racks. In at least one embodiment, homogenous and heterogeneous servers mean that a change from a removed server tray or rack can require a change in coolant flow to the remaining server trays or racks that is not a linear change, but is associated with a non-linear correlation between the cooling requirements of such remaining server trays or racks versus the removed server tray or rack.

[0116] Accordingly, in at least one embodiment, sensors associated with an interface flow controller can be at a rack level for homogenous servers of a rack such that the interface flow controller can provide a linear change in flow for all remaining server trays or racks upon removal of one server tray or rack of the rack. In at least one embodiment, differently, for heterogeneous servers of a rack, sensors associated with an interface flow controller can be at a server level so that the interface flow controller can provide a non-linear change in flow for all remaining server trays or racks of the rack upon removal of a high cooling requirement or low cooling requirement server tray or rack.

[0117] In at least one embodiment, throughout FIGS. 1-4Each of the at least one processors described has inference and / or training logic 615 which can include, without limitation, code and / or data storage 601 to store forward and / or output weights and / or input / output data, and / or other parameters to configure neurons or layers of a neural network being trained and / or used for inference in aspects of one or more embodiments. In at least one embodiment, training logic 615 can include or be coupled to code and / or data storage 601 to store graph code or other software to control timing and / or order, where weight and / or other parameter information can be loaded for configuration of logic including integer and / or floating point units (collectively, arithmetic logic unit(s) (ALUs)). In at least one embodiment, code such as graph code loads weight or other parameter information into processor ALUs based on an architecture of a neural network to which such code corresponds. In at least one embodiment, code and / or data storage 601 stores weight parameters and / or input / output data for each layer of a neural network trained or used in conjunction with one or more embodiments during training and / or forward propagation of input / output data and / or weight parameters during inference using aspects of one or more embodiments. In at least one embodiment, any portion of code and / or data storage 601 can be included with other on-chip or off-chip data storage, including a processor’s LI, L2, or L3 cache or system memory.

[0118] FIG. 5 A method 500 associated with a data center cooling system of FIGS. 2-4 is shown, in accordance with at least one embodiment. In at least one embodiment, method 500 includes providing (502) a first interface flow controller that includes a sensor and is associated with a first server tray of a rack. In at least one embodiment, method 500 includes enabling the first interface flow controller to receive sensor input and communicate with a second interface flow controller over a communication line therebetween (504). In at least one embodiment, method 500 includes associating (506) the second interface flow controller with a CDU. In at least one embodiment, method 500 includes determining (508) that a change in coolant flow has occurred from the sensor input. In at least one embodiment, step 506 can be repeated where such association (506) can be to enable continued coolant flow by the second interface flow controller.

[0119] In at least one embodiment, step 508 can be performed in other ways. In at least one embodiment, method 500 includes causing (508), by the second interface flow controller, balancing of coolant flow from the CDU to one or more second server trays based in part on a change in coolant flow to the first server tray as indicated by such sensor input. In at least one embodiment, method (500) herein includes steps or substeps for determining, using at least one processor, from such sensor input that a disconnection associated with the first interface flow controller has occurred based in part on the change in coolant flow. In at least one embodiment, method (500) herein includes steps or substeps for causing, by the second interface flow controller, balancing of coolant flow from the CDU to one or more second server trays.

[0120] In at least one embodiment, method (500) herein includes steps or substeps for providing, by a sensor, such sensor input to at least one processor. In at least one embodiment, such sensor input is provided upon a first server tray being disconnected from a first interface flow controller. In at least one embodiment, such sensor input can enable the second interface flow controller to cause a change in coolant flow. In at least one embodiment, method (500) herein includes steps or substeps for associating at least one processor with the first interface flow controller.

[0121] In at least one embodiment, method (500) herein includes steps or substeps for enabling, by at least one processor, the first interface flow controller to receive such sensor input. In at least one embodiment, at least one processor can be in communication with the second interface flow controller over a communication line. In at least one embodiment, method (500) herein includes steps or substeps for determining, by at least one processor, that a first server tray is disconnected from a first interface flow controller based in part on such sensor input indicating a change in coolant flow. In at least one embodiment, method (500) herein includes steps or substeps for enabling, by at least one processor, the second interface flow controller to cause balancing of coolant flow from a CDU to one or more second server trays.

[0122] In at least one embodiment, method (500) herein includes steps or substeps for providing, by a sensor, such sensor input to at least one processor located within a first interface flow controller for indicating that a first server tray is disconnected from the first interface flow controller. In at least one embodiment, method (500) herein includes steps or substeps for causing, by a second interface flow controller, balancing of coolant flow from a CDU based in part on input from at least one processor to the second interface flow controller.

[0123] Inference and training logic

[0124] FIG. 6A Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6 A and / or 6B. FIG. 6A and / or FIG. 6B Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6A and / or 6B.

[0125] In at least one embodiment, inference and / or training logic 615 can include, without limitation, code and / or data memory 601 for storing forward and / or output weights and / or input / output data, and / or other parameters for configuring neurons or layers of a neural network being trained and / or used for inferencing in aspects of one or more embodiments. In at least one embodiment, training logic 615 can include or be coupled to code and / or data memory 601 to store graph code or other software for controlling timing and / or order, in which weight and / or other parameter information is to be loaded to configure logic, including integer and / or floating point units (collectively, arithmetic logic unit(s) (ALUs)). In at least one embodiment, code, such as graph code, loads weight or other parameter information into processor ALUs based on an architecture of a neural network to which this code corresponds. In at least one embodiment, code and / or data memory 601 stores weight parameters and / or input / output data for each layer of a neural network that is trained in conjunction with one or more embodiments during forward propagation of input / output data and / or weight parameters during training and / or use of one or more embodiments. In at least one embodiment, any portion of code and / or data memory 601 can be included with other on-chip or off-chip data storage, including a processor’s L1, L2, or L3 cache or system memory.

[0126] In at least one embodiment, any portion of code and / or data memory 601 can be internal or external to one or more processors or other hardware logic devices or circuits. In at least one embodiment, code and / or data memory 601 can be a cache memory, dynamic random- addressable memory (“DRAM”), static random- addressable memory (“SRAM”), non-volatile memory (e.g., Flash), or other memory. In at least one embodiment, whether code and / or data memory 601 is internal or external to a processor, e.g., or includes DRAM, SRAM, Flash, or some other memory type, can depend on available storage on-chip versus off-chip, latency requirements of training and / or inferencing functions being performed, batch size of data being used in inferencing and / or training of a neural network, or some combination of these or other factors.

[0127] In at least one embodiment, inference and / or training logic 615 can include, without limitation, code and / or data memory 605 for storing backward and / or output weights and / or input / output data corresponding to neurons or layers of a neural network being trained and / or used for inferencing in aspects of one or more embodiments. In at least one embodiment, code and / or data memory 605 stores weight parameters and / or input / output data of each layer of a neural network that is trained in conjunction with one or more embodiments during backward propagation of input / output data and / or weight parameters during training and / or inferencing using aspects of one or more embodiments. In at least one embodiment, training logic 615 can include, or be coupled to, code and / or data memory 605 to store graphics code or other software to control timing and / or sequence in which weights and / or other parameter information will be loaded to configure logic, including integer and / or floating point units (collectively, arithmetic logic units (ALUs)).

[0128] In at least one embodiment, code, such as graphics code, loads weight or other parameter information into processor ALUs based on an architecture of a neural network to which this code corresponds. In at least one embodiment, any portion of code and / or data storage 605 can be included with other on-chip or off-chip data storage, including a processor’s LI, L2, or L3 cache or system memory. In at least one embodiment, any portion of code and / or data memory 605 can be internal or external to one or more processors or other hardware logic devices or circuits. In at least one embodiment, code and / or data memory 605 can be cache memory, DRAM, SRAM, non-volatile memory (e.g., Flash memory), or other memory. In at least one embodiment, a choice of whether code and / or data memory 605 is internal or external to a processor, e.g., or includes DRAM, SRAM, Flash, or some other storage type, can depend on available on-chip versus off-chip memory, latency requirements of training and / or inferencing functions being performed, batch size of data used in inferencing and / or training of a neural network, or some combination of these factors.

[0129] In at least one embodiment, code and / or data memory 601 and code and / or data memory 605 can be separate storage structures. In at least one embodiment, code and / or data memory 601 and code and / or data memory 605 can be a combined storage structure. In at least one embodiment, code and / or data memory 601 and code and / or data memory 605 can be partially combined and partially separate. In at least one embodiment, any portion of code and / or data memory 601 and code and / or data memory 605 can be included with other on-chip or off-chip data storage, including a processor’s LI, L2, or L3 cache or system memory.

[0130] In at least one embodiment, inference and / or training logic 615 can include, without limitation, one or more arithmetic logic units (“ALUs”), including integer and / or floating-point units, to perform logical and / or mathematical operations based, at least in part, on or indicated by instructions or other code, the results of which can produce activations (e.g., output values from layers or neurons within a neural network) stored in activation memory 620 that are functions of input / output and / or weight parameter data stored in code and / or data memory 601 and / or code and / or data memory 605. In at least one embodiment, activations stored in activation memory 620 are generated in accordance with linear algebra and / or matrix-based mathematical operations performed by one or more ALUs 610 in response to execution of instructions or other code, with weight values stored in code and / or data memory 605 and / or code and / or data memory 601 used as operands along with other values, such as bias values, gradient information, momentum values, or other parameters or hyperparameters, any or all of which can be stored in code and / or data memory 605 or code and / or data memory 601 or another on-chip or off-chip memory.

[0131] In at least one embodiment, one or more ALUs 610 are included in one or more processors or other hardware logic devices or circuits, while in another embodiment, one or more ALUs 610 can be external to a processor or other hardware logic device or circuit that uses them (e.g., a co-processor). In at least one embodiment, ALUs 610 can be included within execution units of a processor or otherwise included in a group of ALUs that are accessible by execution units of a processor, either within a same processor or distributed between different types of different processors (e.g., central processing units, graphics processing units, fixed function units, etc.). In at least one embodiment, code and / or data memory 601, code and / or data memory 605, and activation memory 620 can be shared on a processor or other hardware logic device or circuit, while in another embodiment, they can be in different processors or other hardware logic devices or circuits, or some combination of same and different processors or other hardware logic devices or circuits. In at least one embodiment, any portion of activation memory 620 can be included with other on-chip or off-chip data memory including L1, L2, or L3 caches of a processor or system memory. Moreover, inference and / or training code can be stored with other code accessible by a processor or other hardware logic or circuit, and fetched and / or processed using fetch, decode, schedule, execute, retire, and / or other logic circuits of a processor.

[0132] In at least one embodiment, activation memory 620 can be cache memory, DRAM, SRAM, non-volatile memory (e.g., Flash), or other memory. In at least one embodiment, activation memory 620 can be entirely or partially within or outside of one or more processors or other logic circuits. In at least one embodiment, whether activation memory 620 is internal or external to a processor, e.g., or includes DRAM, SRAM, Flash, or some other storage type, can depend on available storage on-chip versus off-chip, latency requirements of training and / or inferencing functions being performed, batch size of data used in inferencing and / or training of a neural network, or some combination of these factors.

[0133] In at least one embodiment, FIG. 6A Inference and / or training logic 615 as shown in FIG. 15 can be used in conjunction with a processing unit from Google TM , an inference processing unit (IPU) from Graphcore (e.g., “Lake Crest”) processor from Intel Corp. In at least one embodiment, inference and / or training logic 615 can be used with other processors in FIG. 6AThe inference and / or training logic 615 shown can be used in conjunction with central processing unit (“CPU”) hardware, graphics processing unit (“GPU”) hardware or other hardware such as field programmable gate array (“FPGA”)

[0134] FIG. 6B An inference and / or training logic 615 according to at least one embodiment is illustrated. In at least one embodiment, the inference and / or training logic 615 may include, but is not limited to, hardware logic in which computational resources are dedicated or otherwise used specifically in conjunction with weight values ​​or other information corresponding to one or more neuron layers within a neural network. In at least one embodiment, FIG. 6B The inference and / or training logic 615 shown can be used in conjunction with an application-specific integrated circuit (ASIC), such as those from Google. Processing unit, from Graphcore TM Inference processing unit (IPU), or from Intel Corporation (For example, a "Lake Crest" processor. In at least one embodiment, FIG. 6B The inference and / or training logic 615 shown can be used in conjunction with central processing unit (CPU) hardware, graphics processing unit (GPU) hardware, or other hardware such as a field-programmable gate array (FPGA). In at least one embodiment, the inference and / or training logic 615 includes, but is not limited to, code and / or data memories 601 and 605, which can be used to store code (e.g., graphical code), weight values, and / or other information, including bias values, gradient information, momentum values, and / or other parameter or hyperparameter information. FIG. 6B In at least one embodiment shown, each of code and / or data memory 601 and code and / or data memory 605 is associated with a dedicated computing resource (such as computing hardware 602 and computing hardware 606). In at least one embodiment, each of computing hardware 602 and computing hardware 606 includes one or more ALUs that perform mathematical functions (such as linear algebraic functions) on information stored in code and / or data memory 601 and code and / or data memory 605, respectively, and the results are stored in activation memory 620.

[0135] In at least one embodiment, each of code and / or data memories 601 and 605 and corresponding computing hardware 602 and 606, respectively, correspond to different layers of a neural network, such that resulting activations from one “memory / computing pair 601 / 602” are provided as input to next memory / computing pair 605 / 606 of code and / or data memory 605 and computing hardware 606, respectively, in order to reflect conceptual organization of neural network.

[0136] In at least one embodiment, each of memory / computing pairs 601 / 602 and 605 / 606 can correspond to more than one neural network layer. In at least one embodiment, additional memory / computing pairs (not shown) following or in parallel with memory computing pairs 601 / 602 and 605 / 606 can be included in inferencing and / or training logic 615.

[0137] Neural network training and deployment

[0138] FIG. 7 Training and deployment of a deep neural network is shown, in accordance with at least one embodiment. In at least one embodiment, an untrained neural network 706 is trained using a training dataset 702. In at least one embodiment, training framework 704 is a PyTorch framework, while in other embodiments, training framework 704 is TensorFlow, Boost, Caffe, Microsoft Cognitive Toolkit / CNTK, MXNet, Chainer, Keras, Deeplearning4j, or other training framework. In at least one embodiment, training framework 704 trains untrained neural network 706 and enables it to be trained using processing resources described herein to generate a trained neural network 708. In at least one embodiment, weights can be chosen at random or by pre-training using a deep belief network. In at least one embodiment, training can be performed in a supervised, partially supervised, or unsupervised manner.

[0139] In at least one embodiment, a supervised learning is used to train untrained neural network 706, where training dataset 702 includes inputs paired with desired outputs for inputs, or where training dataset 702 includes inputs with known outputs and outputs of neural network 706 are manually graded. In at least one embodiment, untrained neural network 706 is trained in a supervised manner and processes inputs from training dataset 702 and compares resulting outputs to a set of desired or wanted outputs. In at least one embodiment, errors are then propagated backwards through untrained neural network 706. In at least one embodiment, training framework 704 adjusts weights that control untrained neural network 706. In at least one embodiment, training framework 704 includes tools for monitoring how well untrained neural network 706 is converging toward a model suitable for generating correct answers (such as results 714) based on input data (such as new dataset 712), such as trained neural network 708. In at least one embodiment, training framework 704 trains untrained neural network 706 repeatedly while adjusting weights to refine outputs of untrained neural network 706 using a loss function and adjustment algorithm, such as stochastic gradient descent. In at least one embodiment, training framework 704 trains untrained neural network 706 until untrained neural network 706 reaches a desired level of accuracy. In at least one embodiment, trained neural network 708 can then be deployed to implement any number of machine learning operations.

[0140] In at least one embodiment, an unsupervised learning is used to train untrained neural network 706, where untrained neural network 706 attempts to train itself using unlabeled data. In at least one embodiment, unsupervised learning training dataset 702 will include input data without any associated output data or “ground truth” data. In at least one embodiment, untrained neural network 706 can learn groupings within training dataset 702 and can determine how individual inputs relate to untrained dataset 702. In at least one embodiment, unsupervised training can be used to generate a self-organizing map in trained neural network 708, which can perform operations useful for reducing dimensionality of new dataset 712. In at least one embodiment, unsupervised training can also be used to perform anomaly detection, which allows for identification of data points in new dataset 712 that deviate from normal patterns of new dataset 712.

[0141] In at least one embodiment, semi-supervised learning can be used, which is a technique in which a mix of labeled and unlabeled data is included in training dataset 702. In at least one embodiment, training framework 704 can be used to perform incremental learning, such as through transfer learning techniques. In at least one embodiment, incremental learning enables trained neural network 708 to adapt to new dataset 712 without forgetting knowledge that was imprinted into trained neural network 708 during initial training.

[0142] In at least one embodiment, training framework 704 is a framework that is processed in conjunction with a software development kit such as an OpenVINO (Open Visual Inference and Neural Network Optimization) toolkit. In at least one embodiment, OpenVINO toolkit is a toolkit such as developed by Intel Corporation of Santa Clara, CA.

[0143] In at least one embodiment, OpenVINO is a toolkit for facilitating development of applications, particularly neural network applications, for various tasks and operations such as human vision simulation, speech recognition, natural language processing, recommendation systems, and / or variations thereof. In at least one embodiment, OpenVINO supports neural networks such as convolutional neural networks (CNNs), recurrent neural networks, and / or attention-based neural networks, and / or various other neural network models. In at least one embodiment, OpenVINO supports various software libraries such as OpenCV, OpenCL, and / or variations thereof.

[0144] In at least one embodiment, OpenVINO supports neural network models for various tasks and operations such as classification, segmentation, object detection, facial recognition, speech recognition, pose estimation (e.g., of people and / or objects), monocular depth estimation, image inpainting, style transfer, action recognition, colorization, and / or variations thereof.

[0145] In at least one embodiment, OpenVINO includes one or more software tools and / or modules for model optimization, also referred to as a model optimizer. In at least one embodiment, model optimizer is a command-line tool that facilitates conversion between training and deployment of neural network models. In at least one embodiment, model optimizer optimizes neural network models for execution on various devices and / or processing units such as GPUs, CPUs, PPUs, GPGPUs, and / or variations thereof. In at least one embodiment, model optimizer generates an internal representation of a model and optimizes the model to generate an intermediate representation. In at least one embodiment, model optimizer reduces a number of layers of a model. In at least one embodiment, model optimizer removes layers of a model used for training. In at least one embodiment, model optimizer performs various neural network operations such as modifying an input of a model (e.g., adjusting a size of an input of a model), modifying a size of an input of a model (e.g., modifying a batch size of a model), modifying a model structure (e.g., modifying a layer of a model), normalizing, standardizing, quantizing (e.g., converting a weight of a model from a first representation such as a floating point to a second representation such as an integer), and / or variations thereof.

[0146] In at least one embodiment, OpenVINO includes one or more software libraries for inference, also referred to as an inference engine. In at least one embodiment, inference engine is a C++ library or a library in any suitable programming language. In at least one embodiment, inference engine is used to infer input data. In at least one embodiment, inference engine implements various classes to infer input data and generate one or more results. In at least one embodiment, inference engine implements one or more API functions to process an intermediate representation, set an input and / or output format, and / or execute a model on one or more devices.

[0147] In at least one embodiment, OpenVINO provides various capabilities for heterogeneous execution of one or more neural network models. In at least one embodiment, heterogeneous execution or heterogeneous computing refers to one or more computing processes and / or systems that utilize one or more types of processors and / or cores. In at least one embodiment, OpenVINO provides various software capabilities to execute programs on one or more devices. In at least one embodiment, OpenVINO provides various software capabilities to execute programs and / or portions of programs on different devices. In at least one embodiment, OpenVINO provides various software capabilities, for example, to run a first portion of code on a CPU, a second portion of code on a GPU and / or FPGA. In at least one embodiment, OpenVINO provides various software capabilities to execute one or more layers of a neural network on one or more devices (e.g., a first set of layers on a first device (e.g., GPU) and a second set of layers on a second device (e.g., CPU)).

[0148] In at least one embodiment, OpenVINO includes various capabilities similar to those associated with CUDA programming models, such as various neural network model operations associated with frameworks such as TensorFlow, PyTorch, and / or variants thereof. In at least one embodiment, one or more CUDA programming model operations are performed using OpenVINO. In at least one embodiment, various systems, methods, and / or techniques described herein are implemented using OpenVINO.

[0149] Data Center

[0150] FIG. 8 An example data center 800 that can use at least one embodiment is shown. In at least one embodiment, data center 800 includes a data center infrastructure layer 810, a framework layer 820, a software layer 830, and an application layer 840.

[0151] In at least one embodiment, as FIG. 8As shown, the data center infrastructure layer 810 can include a resource orchestrator 812, grouped computing resources 814, and node computing resources (“node C.R.s”) 816(1)-816(N), where “N” represents a positive integer (which can be a different integer “N” than the integer used in other Figures). In at least one embodiment, the node C.R.s 816(1)-816(N) can include, but are not limited to, any number of central processing units (“CPUs” or “processors”), including accelerators, field programmable gate arrays (FPGAs), graphics processors, and so forth, memory storage devices 818(1)-818(N) (e.g., dynamic read-only memory, solid-state storage, or disk drives), network input / output (“NW I / O”) devices, network switches, virtual machines (“VMs”), power modules, and cooling modules, and so on. In at least one embodiment, one or more of the node C.R.s 816(1)-816(N) can be a server having one or more of the above-described computing resources.

[0152] In at least one embodiment, the grouped computing resources 814 can include individual groups of node C.R.s housed within one or more racks (not shown) or a number of racks housed within data centers (also not shown) at various geographic locations. In at least one embodiment, individual groups of node C.R.s within the grouped computing resources 814 can include groups of computing, network, memory, or storage resources that can be configured or allocated to support one or more workloads. In at least one embodiment, a number of node C.R.s including CPUs or processors can be grouped within one or more racks to provide computing resources to support one or more workloads. In at least one embodiment, one or more racks can also include any number of power modules, cooling modules, and network switches in any combination.

[0153] In at least one embodiment, the resource orchestrator 812 can configure or otherwise control one or more node C.R.s 816(1)-816(N) and / or the grouped computing resources 814. In at least one embodiment, the resource orchestrator 812 can include a software design infrastructure (“SDI”) management entity for the data center 800. In at least one embodiment, the resource orchestrator 812 can comprise hardware, software, or some combination thereof.

[0154] In at least one embodiment, as FIG. 8As shown, framework layer 820 includes a job scheduler 822, a configuration manager 824, a resource manager 826, and a distributed file system 828. In at least one embodiment, framework layer 820 may include a framework of software 832 supporting software layer 830 and / or one or more applications 842 supporting application layer 840. In at least one embodiment, software 832 or application 842 may respectively include web-based service software or applications, such as service software or applications provided by Amazon Web Services, Google Cloud, and Microsoft Azure. In at least one embodiment, framework layer 820 may be, but is not limited to, a type of free and open-source software web application framework, such as Apache Spark, which can leverage distributed file system 828 for large-scale data processing (e.g., "big data"). TM (Hereinafter referred to as "Spark"). In at least one embodiment, the job scheduler 822 may include a Spark driver for facilitating the scheduling of workloads supported by various layers of the data center 800. In at least one embodiment, the configuration manager 824 may be able to configure different layers, such as the software layer 830 and the framework layer 820, which includes Spark and a distributed file system 828 for supporting large-scale data processing. In at least one embodiment, the resource manager 826 may be able to manage clustered or grouped computing resources mapped to or allocated to support the distributed file system 828 and the job scheduler 822. In at least one embodiment, the clustered or grouped computing resources may include grouped computing resources 814 at the data center infrastructure layer 810. In at least one embodiment, the resource manager 826 may coordinate with the resource coordinator 812 to manage these mapped or allocated computing resources.

[0155] In at least one embodiment, the software 832 included in the software layer 830 may include software used by at least portions of nodes CR816(1)-816(N), grouped computing resources 814, and / or the distributed file system 828 of the framework layer 820. In at least one embodiment, one or more types of software may include, but are not limited to, Internet web page search software, email virus scanning software, database software, and streaming video content software.

[0156] In at least one embodiment, one or more applications 842 included in application layer 840 can include one or more types of applications used by at least portions of node C.R.s 816(l)-816(N), grouped computing resources 814, and / or distributed file system 828 of framework layer 820. In at least one embodiment, one or more types of applications can include, but are not limited to, any number and type of genomics applications, cognitive computing, applications, and machine learning applications including training or inferencing software, machine learning framework software (e.g., PyTorch, TensorFlow, Caffe, etc.), or other machine learning applications used in conjunction with one or more embodiments.

[0157] In at least one embodiment, any of configuration manager 824, resource manager 826, and resource orchestrator 812 can implement any number and type of self-modification actions based on any amount and type of data acquired in any technically feasible fashion. In at least one embodiment, self-modification actions can mitigate data center operators of data center 800 making possibly poor configuration decisions and can avoid underutilized and / or poorly performing portions of a data center.

[0158] In at least one embodiment, data center 800 can include tools, services, software, or other resources for training one or more machine learning models or using one or more machine learning models to predict or infer information in accordance with one or more embodiments described herein. For example, in at least one embodiment, a machine learning model can be trained in accordance with a neural network architecture computing weight parameters by using software and computing resources described above with respect to data center 800. In at least one embodiment, a trained machine learning model corresponding to one or more neural networks can be used to infer or predict information using resources described above with respect to data center 800 by using weight parameters computed through one or more training techniques described herein.

[0159] In at least one embodiment, a data center can use CPUs, application specific integrated circuits (ASICs), GPUs, FPGAs, or other hardware to perform training and / or inference using resources described above. Furthermore, one or more software and / or hardware resources described above can be configured as a service for allowing users to train or perform information inference such as image recognition, speech recognition, or other artificial intelligence services.

[0160] Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. In at least one embodiment, inference and / or training logic 615 can be used in FIG. 6A and / or FIG. 6BDetails are provided regarding the inference and / or training logic 615. In at least one embodiment, the inference and / or training logic 615 can be... FIG. 8 It is used in systems for inference or prediction operations based at least in part on weight parameters calculated using the neural network training operations, neural network functions and / or architectures, or neural network use cases described herein.

[0161] In at least one embodiment, one or more neural networks of the inference and / or training logic 615 can be connected with... FIG. 8 The system can be used together and can be configured to receive sensor inputs from multiple sensors, and can be trained to infer coolant demand. In at least one embodiment, the inference and / or training logic 615 is capable of inferring coolant demand using information from historical cooling demand and historical sensor inputs. In at least one embodiment, the inference and / or training logic 615 can infer changes in cooling demand. In at least one embodiment, sensor inputs can be associated with different categories of cooling demand for each different sensor input. In at least one embodiment, new sensor inputs categorized within these different categories of sensor inputs can indicate cooling demand, or changes thereof.

[0162] Computer System

[0163] FIG. 9 This is a block diagram illustrating an exemplary computer system according to at least one embodiment. The exemplary computer system may be a system of interconnected devices and components, a system-on-a-chip (SoC), or some combination thereof formed with a processor, which may include an execution unit for executing instructions. In at least one embodiment, according to this disclosure, such as in the embodiments described herein, computer system 900 may include, but is not limited to, components such as processor 902 for employing execution units (including logic) to execute algorithms for process data. In at least one embodiment, computer system 900 may include a processor, such as those available from Intel Corporation of Santa Clara, California. Processor family, Xeon TM , XScale TM and / or StrongARM TM , Core TM or Nervana TMmicroprocessors, although other systems (including PCs with other microprocessors, engineering workstations, set-top boxes, etc.) can also be used. In at least one embodiment, computer system 900 can execute a version of the WINDOWS operating system available from Microsoft Corporation of Redmond, Wash, although other operating systems (UNIX and Linux, for example), embedded software, and / or graphical user interfaces can also be used.

[0164] Embodiments can be used in other devices such as handheld devices and embedded applications. Some examples of handheld devices include cellular phones, Internet Protocol devices, digital cameras, personal digital assistants (“PDAs”), and handheld PCs. In at least one embodiment, embedded applications can include a microcontroller, a digital signal processor (“DSP”), a system on a chip, a network computer (“NetPC”), a set-top box, a network hub, a wide area network (“WAN”) switch, or any other system that can perform one or more instructions in accordance with at least one embodiment.

[0165] In at least one embodiment, computer system 900 can include, but is not limited to, a processor 902, which can include, but is not limited to, one or more execution units 908 for performing instructions associated with execution of machine learning model training and / or inference in accordance with techniques described herein. In at least one embodiment, computer system 900 is a single processor desktop or server system, although in another embodiment, computer system 900 can be a multiprocessor system. In at least one embodiment, processor 902 can include, but is not limited to, a complex instruction set computer (“CISC”) microprocessor, a reduced instruction set computing (“RISC”) microprocessor, a very long instruction word (“VLIW”) microprocessor, a processor implementing a combo of instruction sets, or any other processor device, such as a digital signal processor. In at least one embodiment, processor 902 is coupled to a processor bus 910 that can transmit data signals between processor 902 and other components in computer system 900.

[0166] In at least one embodiment, processor 902 can include, without limitation, a level 1 (“L1”) internal cache memory (“cache”) 904. In at least one embodiment, processor 902 can have a single internal cache or multiple levels of internal caches. In at least one embodiment, cache memory can reside in the processor’s 902 external. Other embodiments can also include a combination of internal and external caches depending on specific implementation and requirements. In at least one embodiment, register file 906 can store different types of data including, without limitation, integer registers, floating point registers, status registers, and instruction pointer registers in various registers.

[0167] In at least one embodiment, execution unit 908, including, without limitation, logic to perform integer and floating point operations, also resides in processor 902. In at least one embodiment, processor 902 can also include a microcode (“ucode”) read only memory (“ROM”) that stores the microcode for certain macro instructions. In at least one embodiment, execution unit 908 can include logic to handle a packed instruction set 909. In at least one embodiment, by including packed instruction set 909 in instruction set of a general- purpose processor along with associated circuitry to execute instructions, operations used by many multimedia applications can be performed using packed data in processor 902. In at least one embodiment, many multimedia applications can be accelerated and executed more efficiently by using full width of processor’s data bus to perform operations on packed data, which can eliminate need to transfer smaller units of data across processor’s data bus to perform one or more operations one data element at a time.

[0168] In at least one embodiment, execution unit 908 can also be used in microcontrollers, embedded processors, graphics devices, DSPs, and other types of logic circuits. In at least one embodiment, computer system 900 can include, without limitation, memory 920. In at least one embodiment, memory 920 can be a Dynamic Random Access Memory (“DRAM”) device, a Static Random Access Memory (“SRAM”) device, a flash memory device, or other memory devices. In at least one embodiment, memory 920 can store one or more instructions 919 and / or data 921 in the form of data signals representable by processor 902.

[0169] In at least one embodiment, a system logic chip can be coupled to processor bus 910 and memory 920. In at least one embodiment, system logic chip can include, without limitation, a memory controller hub (“MCH”) 916, and processor 902 can communicate with MCH 916 via processor bus 910. In at least one embodiment, MCH 916 can provide a high bandwidth memory path 918 to memory 920 for instruction and data storage and for storage of graphics commands, data, and textures for processing by graphics processor unit 912. In at least one embodiment, MCH 916 can direct data signals between processor 902, memory 920, and other components in computer system 900, and

[0170] In at least one embodiment, computer system 900 can use system I / O interface 922 as a proprietary hub interface bus to couple MCH 916 to I / O controller hub (“ICH”) 930. In at least one embodiment, ICH 930 can provide a direct connection to some I / O devices and can indirect connect other devices via one or more buses, such as a Peripheral Component Interconnect (PCI) bus or another type of bus.

[0171] In at least one embodiment, FIG. 9 A system including interconnected hardware devices or “chips” is shown, while in other embodiments, FIG. 9 An exemplary SoC can be shown. In at least one embodiment, FIG. 9 Devices shown in FIG. 1 can be interconnected with proprietary interconnects, standardized interconnects (e.g., PCIe), or some combination thereof. In at least one embodiment, one or more components of computer system 900 are interconnected using a Compute Express Link (CXL) interconnect.

[0172] Inference and / or training logic 615 is used to perform inference and / or training operations associated with one or more embodiments. This document combines... FIG. 6A and / or FIG. 6B Details are provided regarding the inference and / or training logic 615. In at least one embodiment, the inference and / or training logic 615 can be... FIG. 9 Used in systems for inference or prediction operations based at least in part on weight parameters computed using neural network training operations, neural network functions and / or architectures, or neural network use cases as described herein.

[0173] In at least one embodiment, one or more neural networks of the inference and / or training logic 615 can be connected with... FIG. 9 The features are used in combination and can be configured to receive sensor inputs from multiple sensors, and can be trained to infer coolant demand. In at least one embodiment, the inference and / or training logic 615 is capable of inferring coolant demand using information from historical cooling demand and historical sensor inputs. In at least one embodiment, the inference and / or training logic 615 can infer changes in cooling demand. In at least one embodiment, sensor inputs can be associated with different categories of cooling demand for each different sensor input. In at least one embodiment, a new sensor input categorized within such different sensor input categories may indicate cooling demand, or changes thereof.

[0174] FIG. 10 This is a block diagram illustrating an electronic device 1000 for utilizing a processor 1010 according to at least one embodiment. In at least one embodiment, the electronic device 1000 may be, for example, but not limited to, a laptop computer, tower server, rack server, blade server, laptop computer, desktop computer, tablet computer, mobile device, telephone, embedded computer, or any other suitable electronic device.

[0175] In at least one embodiment, the electronic device 1000 may, but is not limited to, a processor 1010 communicatively coupled to any suitable number or type of components, peripherals, modules, or devices. In at least one embodiment, the processor 1010 is coupled using a bus or interface, such as I... 2 C-bus, System Management Bus (“SMBus”), Low Pin Count (LPC) bus, Serial Peripheral Interface (“SPI”), High Definition Audio (“HDA”) bus, Serial Advanced Technology Accessory (“SATA”) bus, Universal Serial Bus (“USB”) (versions 1, 2, 3, etc.), or Universal Asynchronous Receiver / Transmitter (“UART”) bus. In at least one embodiment, FIG. 10Systems can be shown that include interconnected hardware devices or “chips,” while in other embodiments, FIG. 10 An exemplary SoC can be shown. In at least one embodiment, FIG. 10 Devices shown in FIG. 6B can be interconnected with proprietary interconnects, standardized interconnects (e.g., PCIe), or some combination thereof. In at least one embodiment, FIG. 10 One or more components of FIG. 6B are interconnected using a compute express link (CXL) interconnect.

[0176] In at least one embodiment, FIG. 10 may include a display 1024, a touch screen 1025, a touch pad 1030, a near field communication unit (“NFC”) 1045, a sensor hub 1040, a thermal sensor 1046, an express chipset (“EC”) 1035, a trusted platform module (“TPM”) 1038, a BIOS / firmware / flash memory (“BIOS, FW Flash”) 1022, a DSP 1060, a drive 1020 such as a solid state disk (“SSD”) or a hard disk drive (“HDD”), a wireless local area network unit (“WLAN”) 1050, a Bluetooth unit 1052, a wireless wide area network unit (“WWAN”) 1056, a global positioning system (“GPS”) unit 1055, a camera (“USB 3.0 camera”) 1054 such as a USB 3.0 camera, and / or a low power double data rate (“LPDDR”) memory unit (“LPDDR3”) 1015 implemented in, for example, LPDDR3 standard. These components can each be implemented in any suitable manner.

[0177] In at least one embodiment, other components may be communicatively coupled to processor 1010 via the components described herein. In at least one embodiment, accelerometer 1041, ambient light sensor (“ALS”) 1042, compass 1043, and gyroscope 1044 may be communicatively coupled to sensor hub 1040. In at least one embodiment, thermal sensor 1039, fan 1037, keyboard 1036, and touchpad 1030 may be communicatively coupled to EC 1035. In at least one embodiment, speaker 1063, earphone 1064, and microphone (“mic”) 1065 may be communicatively coupled to audio unit (“audio codec and Class D amplifier”) 1062, which in turn may be communicatively coupled to DSP 1060. In at least one embodiment, audio unit 1062 may include, for example, but not limited to, audio encoder / decoder (“codec”) and Class D amplifier. In at least one embodiment, SIM card (“SIM”) 1057 may be communicatively coupled to WWAN unit 1056. In at least one embodiment, components such as WLAN unit 1050, Bluetooth unit 1052, and WWAN unit 1056 may be implemented as next-generation form factors (“NGFF”).

[0178] Inference and / or training logic 615 is used to perform inference and / or training operations associated with one or more embodiments. This document combines... FIG. 6A and / or FIG. 6B Details are provided regarding the inference and / or training logic 615. In at least one embodiment, the inference and / or training logic 615 can be... FIG. 10 Used in systems for inference or prediction operations based at least in part on weight parameters computed using neural network training operations, neural network functions and / or architectures, or neural network use cases as described herein.

[0179] In at least one embodiment, one or more neural networks of the inference and / or training logic 615 can be connected with... FIG. 10 The features are used together and can be configured to receive sensor inputs from multiple sensors, and can be trained to infer coolant demand. In at least one embodiment, the inference and / or training logic 615 is capable of inferring coolant demand using information from historical cooling demand and historical sensor inputs. In at least one embodiment, the inference and / or training logic 615 can infer changes in cooling demand. In at least one embodiment, sensor inputs can be associated with different categories of cooling demand for each different sensor input. In at least one embodiment, new sensor inputs categorized within these different categories of sensor inputs can indicate cooling demand, or changes thereof.

[0180] FIG. 11A computer system 1100 according to at least one embodiment is shown. In at least one embodiment, computer system 1100 is configured to implement various processes and methods described throughout this disclosure.

[0181] In at least one embodiment, computer system 1100 includes, without limitation, at least one central processing unit (“CPU”) 1102 that is connected to a communication bus 1110 that is implemented using any suitable protocol, such as PCI (“Peripheral Component Interconnect”), peripheral component interconnect express (“PCI-Express”), AGP (“Accelerated Graphics Port”), HyperTransport, or any other bus or point-to-point communication protocol. In at least one embodiment, computer system 1100 includes, without limitation, a main memory 1104 and control logic (e.g., implemented in hardware, software, or a combination thereof) and data are stored in the main memory 1104, which can take form of random access memory (“RAM”). In at least one embodiment, a network interface subsystem (“network interface”) 1122 provides an interface to other computing devices and networks for receiving data from other systems and for transmitting data to other systems using computer system 1100.

[0182] In at least one embodiment, computer system 1100 includes, without limitation, an input device 1108, parallel processing system 1112, and display device 1106, which can be implemented using a conventional cathode ray tube (“CRT”), liquid crystal display (“LCD”), light emitting diode (“LED”), plasma display, or other suitable display technologies. In at least one embodiment, user input is received from input device 1108 such as a keyboard, mouse, touchpad, microphone, or the like. In at least one embodiment, each module described herein can be located on a single semiconductor platform.

[0183] Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. FIG. 6A and / or FIG. 6B Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 can be used in a system to perform inferencing or predicting operations based, at least in part, on weight parameters calculated using neural network training operations described herein. FIG. 11 Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 can be used in a system to perform inferencing or predicting operations based, at least in part, on weight parameters calculated using neural network training operations described herein.

[0184] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used in conjunction with a system to perform inferencing or predicting operations based, at least in part, on weight parameters calculated using neural network training operations described herein. FIG. 11The features of the system 600 can be used in combination and can be configured to receive sensor inputs from multiple sensors and can be trained to infer coolant demand. In at least one embodiment, the inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor inputs to infer coolant demand. In at least one embodiment, the inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor inputs can be correlated to different classes of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such a different class of sensor inputs can be indicative of a cooling demand, or a change thereof.

[0185] FIG. 12 A computer system 1200, in accordance with at least one embodiment, is shown. In at least one embodiment, computer system 1200 includes, without limitation, a computer 1210 and a USB stick 1220. In at least one embodiment, computer 1210 can include, without limitation, any number and type of processor (not shown) and memory (not shown). In at least one embodiment, computer 1210 includes, without limitation, a server, a cloud instance, a laptop computer, and a desktop computer.

[0186] In at least one embodiment, USB stick 1220 includes, without limitation, a processing unit 1230, a USB interface 1240, and USB interface logic 1250. In at least one embodiment, processing unit 1230 can be any instruction execution system, apparatus, or device capable of executing instructions. In at least one embodiment, processing unit 1230 can include, without limitation, any number and type of processing core (not shown). In at least one embodiment, processing unit 1230 comprises an application-specific integrated circuit (“ASIC”) optimized to perform any number and type of operations associated with machine learning. For example, in at least one embodiment, processing unit 1230 is a tensor processing unit (“TPC”) optimized to perform machine learning inference operations. In at least one embodiment, processing unit 1230 is a visual processing unit (“VPU”) optimized to perform machine vision and machine learning inference operations.

[0187] In at least one embodiment, USB interface 1240 can be any type of USB connector or USB receptacle. For example, in at least one embodiment, USB interface 1240 is a USB 3.0 Type-C receptacle for data and power. In at least one embodiment, USB interface 1240 is a USB 3.0 Type-A connector. In at least one embodiment, USB interface logic 1250 can include any number and type of logic that enables processing unit 1230 to interface with a device (e.g., computer 1210) via USB connector 1240.

[0188] Inference and / or training logic 615 are used in the FIG. 6A and / or FIG. 6B Details regarding inference and / or training logic 615 are provided below in conjunction with FIGs. 6L-6P. In at least one embodiment, inference and / or training logic 615 can be used in system FIGs. 1, 2, 3, 4, 5, 6A-6J, 7, 8, and / or 9. FIG. 12 Inference and / or training logic 615 are used in the

[0189] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used in conjunction with features of FIG. 12 and can be trained to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor input to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor input can be correlated to a different class of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such a different class of sensor input can be indicative of a cooling demand, or a change therein.

[0190] FIG. 13A An exemplary architecture is shown in which a plurality of GPUs 1310(1)-1310(N) are communicatively coupled to a plurality of multi-core processors 1305(1)-1305(M) over high-speed links 1340(1)-1340(N) (e.g., buses, point-to-point interconnects, etc.). In at least one embodiment, high-speed links 1340(1)-1340(N) support a communication throughput of 4GB / s, 30GB / s, 80GB / s or higher. In at least one embodiment, various interconnect protocols can be used including, but not limited to, PCIe 4.0 or 5.0, and NVLink 2.0. In various figures, “N” and “M” represent positive integers, and values of “N” and “M” can vary from figure to figure. In at least one embodiment, one or more of the plurality of GPUs 1310(1)-1310(N) includes an I / O FIG. 16A and FIG. 16Bone or more graphics cores (also referred to simply as“cores”) 1600. In at least one embodiment, one or more graphics cores 1600 can be referred to as stream multi- processors (“SMs”), stream processors (“SPs”), stream processing units (“SPUs”), compute units (“CUs”), execution units (“EUs”), and / or slices, where in present context, a slice can refer to a portion of processing resources in a processing unit (e.g., 16 cores, a ray-tracing unit, a thread director or scheduler).

[0191] In addition, in at least one embodiment, two or more GPUs 1310 are interconnected over high-speed links 1329(1)-1329(2), which can be implemented using similar or different protocols / links than those used for high-speed links 1340(1)-1340(N). Similarly, two or more multi-core processors 1305 can be connected over a high-speed link 1328, which can be a symmetric multi-processor (SMP) bus that runs at 20 GB / s, 30 GB / s, 120 GB / s or higher. Alternatively, similar protocols / links (e.g., over common interconnect fabric) can be used to accomplish FIG. 13A all communication between various system components shown in FIG. 13.

[0192] In at least one embodiment, each multi-core processor 1305 is communicatively coupled to processor memories 1301(1)-1301(M) via memory interconnects 1326(1)- 1326(M), respectively, and each GPU 1310(1)-1310(N) is communicatively coupled to GPU memories 1320(1)-1320(N) over GPU memory interconnects 1350(1)-1350(N), respectively. In at least one embodiment, memory interconnects 1326 and 1350 can utilize similar or different memory access technologies. By way of example, but not limitation, processor memories 1301(1)-1301(M) and GPU memories 1320 can be volatile memories such as dynamic random access memory (DRAM) (including stacked DRAM), graphics DDR SDRAM (GDDR) (e.g., GDDR5, GDDR6), or high-bandwidth memory (HBM), and / or can be non-volatile memories such as 3D XPoint or Nano-Ram. In at least one embodiment, certain portions of processor memories 1301 can be volatile memory, while another portion can be non-volatile memory (e.g., using a two-level memory (2LM) hierarchy).

[0193] As described herein, although individual multi-core processors 1305 and GPUs 1310 can be physically coupled to particular memories 1301, 1320, respectively, and / or a unified memory architecture can be implemented in which a virtual system address space (also referred to as an “effective address” space) is distributed among the individual physical memories. For example, processor memories 1301(1)-1301(M) can each include 64 GB of system memory address space, and GPU memories 1320(1)-1320(N) can each include 32 GB of system memory address space, resulting in a total of 256 GB of addressable memory when M = 2 and N = 4. Other values of N and M are possible.

[0194] FIG. 13B Additional details for interconnection between multi-core processor 1307 and graphics acceleration module 1346 are shown according to one exemplary embodiment. In at least one embodiment, graphics acceleration module 1346 can include one or more GPU chips integrated on a line card that is coupled via a high-speed link 1340 (e.g., a PCIe bus, NVLink, etc.) to processor 1307. In at least one embodiment, graphics acceleration module 1346 can alternatively be integrated on a package with processor 1307 or on a chip with processor 1307.

[0195] In at least one embodiment, processor 1307 includes a number of cores 1360A-1360D (which can be referred to as “execution units”) each having a translation lookaside buffer (“TLB”) 1361A-1361D and one or more caches 1362A-1362D. In at least one embodiment, cores 1360A-1360D can include various other components not shown for purposes of brevity including, for example, instruction fetch units, alias logic, and out-of-order instruction completion logic. In at least one embodiment, caches 1362A-1362D can include level 1 (LI) and level 2 (L2) caches. Additionally, one or more shared caches 1356 can be included in caches 1362A-1362D and shared by groups of cores 1360A-1360D. For example, one embodiment of processor 1307 includes 24 cores, each core having its own LI cache, 12 shared L2 caches, and 12 shared L3 caches. In that embodiment, two adjacent cores share one or more L2 and L3 caches. In at least one embodiment, processor 1307 and graphics acceleration module 1346 interface with system memory 1314, which can include processor memories 1301(1)-1301(M) in FIG. 13A

[0196] ​In at least one embodiment, coherence for data and instructions stored in respective caches 1362A-1362D, 1356, and system memory 1314 is maintained by inter-core communications over coherence bus 1364. In at least one embodiment, each cache can have cache coherence logic / circuitry associated with it to communicate over coherence bus 1364 in response to detecting a read or write to a particular cache line. In at least one embodiment, a cache snoop protocol is implemented over coherence bus 1364 to snoop cache accesses.

[0197] In at least one embodiment, agent circuit 1325 communicatively couples graphics acceleration module 1346 to coherence bus 1364, allowing graphics acceleration module 1346 to participate in cache coherence protocol as a peer to cores 1360A-1360D. In particular, in at least one embodiment, interface 1335 provides connectivity from graphics acceleration module 1346 to agent circuit 1325 over high-speed link 1340, and interface 1337 connects graphics acceleration module 1346 to high-speed link 1340.

[0198] In at least one embodiment, accelerator integration circuit 1336 provides the multiple graphics processing engines 1331(1)-1331(N) of graphics acceleration module 1346 with cache management, memory access, context management, and interrupt management services. This allows graphics acceleration module 1346 to be configured to operate as a graphics co-processor and / or graphics acceleration module for graphics processing engine(s) 1310 of core 1300. FIG. 16A and 16B In at least one embodiment, graphics processing engines 1331(1)-1331(N) can each include a separate graphics processing unit (GPU). In at least one embodiment, the multiple graphics processing engines 1331(1)-1331(N) of graphics acceleration module 1346 comprise a GPU, as discussed below in more detail in conjunction with FIG. 6. In at least one embodiment, graphics processing engines 1331(1)-1331(N) alternatively can include different types of graphics processing engines within a GPU, such as graphics execution units, media processing engines (e.g., video encoders / decoders), samplers, and blit engines. In at least one embodiment, graphics acceleration module 1346 can be a GPU with the multiple graphics processing engines 1331(1)-1331(N) or the graphics processing engines 1331(1)-1331(N) can be individual GPUs integrated on a common package, line card, or chip.

[0199] In at least one embodiment, accelerator integration circuit 1336 includes a memory management unit (MMU) 1339 to process memory read and write requests between graphics processing engines 1331(1)-1331(N) and system memory 1314, in at least one embodiment, MMU 1339 includes address translation lookaside buffer (TLB) to perform translation of virtual addresses into physical addresses.

[0200] In at least one embodiment, a set of registers 1345 store program counter values and other context data for threads executing on graphics processing engines 1331(1)-1331(N). In at least one embodiment, context management circuit 1348 manages a plurality of threads executing on graphics processing engines 1331(1)-1331(N) and their various states. In at least one embodiment, threads of a batch of threads execute sequentially with one thread after another, for example, upon a single instruction multiple data (SIMD) core. In at least one embodiment, threads of a batch of threads are executed concurrently, for example, upon a multiple instruction multiple data (MIMD) core.

[0201] In at least one embodiment, MMU 1339 translates virtual / effective addresses from graphics processing engines 1331 into real / physical addresses in system memory 1314. In at least one embodiment, accelerator integration circuit 1336 supports a number of graphics accelerator modules 1346 and / or other accelerator devices (e.g., 4, 8, 16). In at least one embodiment, graphics accelerator modules 1346 can be dedicated to a single application executing on processor 1307 or can be shared between multiple applications. In at least one embodiment, a virtualized graphics execution environment is presented in which resources of graphics processing engines 1331(1)-1331(N) are shared with multiple applications or virtual machines (VMs). In at least one embodiment, resources can be subdivided into “slices” that are allocated to different VMs and / or applications based on processing requirements and priorities associated with the VMs and / or applications.

[0202] In at least one embodiment, accelerator integration circuit 1336 performs as a bridge to system for a system of graphics acceleration modules 1346 and provides address translation and system memory cache services. Further, in at least one embodiment, accelerator integration circuit 1336 can provide virtualization facilities for a host processor to manage virtualization of graphics processing engines 1331(1)-1331(N), interrupts, and memory management.

[0203] In at least one embodiment, because hardware resources of graphics processing engines 1331(1)-1331(N) are explicitly mapped to real address space seen by host processor 1307, any host processor can directly address these resources using effective address values. In at least one embodiment, one function of accelerator integration circuit 1336 is physical separation of graphics processing engines 1331(1)-1331(N) so that they appear as independent units to a system.

[0204] In at least one embodiment, one or more graphics memories 1333(1)-1333(M) are respectively coupled to each graphics processing engines 1331(1)-1331(N), and N=M. In at least one embodiment, graphics memories 1333(1)-1333(M) store instructions and data being processed by each of the graphics processing engines 1331(1)-1331(N). In at least one embodiment, graphics memories 1333(1)-1333(M) can be volatile memory such as DRAM (including stacked DRAM), GDDR memory (e.g., GDDR5, GDDR6), or HBM, and / or can be non-volatile memory such as 3D XPoint or Nano-Ram.

[0205] In at least one embodiment, to reduce data traffic on high-speed link 1340, bias techniques can be used to ensure that data stored in graphics memory 1333(1)-1333(M) is that which is most frequently used by graphics processing engines 1331(1)-1331(N) and is preferably data that is not used (at least not frequently) by cores 1360A-1360D. Similarly, in at least one embodiment, bias mechanisms attempt to keep data needed by the cores and preferably not needed by graphics processing engines 1331(1)-1331(N) in caches 1362A-1362D, 1356, and system memory 1314.

[0206] FIG. 13C Another exemplary embodiment is shown in which accelerator integration circuit 1336 is integrated within processor 1307. In this embodiment, graphics processing engines 1331(1)-1331(N) communicate directly over high-speed link 1340 to accelerator integration circuit 1336 via interface 1337 and interface 1335 (which can also be any form of bus or interface protocol, as described above). In at least one embodiment, accelerator integration circuit 1336 can perform similar operations to those described above with respect to accelerator 1305, but can have higher throughput due to its close proximity and access to coherent bus 1364 and caches 1362A-1362D, 1356. In at least one embodiment, accelerator integration circuit 1336 supports different programming models including a process- dedicated programming model (no graphics acceleration module virtualization) and a shared programming model (with virtualization), which can include programming models controlled by accelerator integration circuit 1336 and programming models controlled by graphics acceleration module 1346. FIG. 13B

[0207] In at least one embodiment, graphics processing engines 1331(1)-1331(N) are dedicated to a single application or process under a single operating system. In at least one embodiment, a single application can funnel other application requests to graphics processing engines 1331(1)-1331(N), providing virtualization within a VM / partition.

[0208] ​In at least one embodiment, graphics processing engines 1331(1)-1331(N) can be shared by multiple VM / application partitions. In at least one embodiment, a shared model can use a hypervisor to virtualize graphics processing engines 1331(1)-1331(N) to allow access by each operating system. In at least one embodiment, for a single-partition system without a hypervisor, an operating system owns graphics processing engines 1331(1)-1331(N). In at least one embodiment, an operating system can virtualize graphics processing engines 1331(1)-1331(N) to provide access to each process or application.

[0209] In at least one embodiment, graphics acceleration module 1346 or individual graphics processing engines 1331(1)-1331(N) use a process handle to select a process element. In at least one embodiment, process elements are stored in system memory 1314 and can be addressed using effective to real address translation techniques described herein. In at least one embodiment, a process handle can be an implementation-specific value provided to a host process when registering its context with a graphics processing engine 1331(1)-1331(N) (i.e., calling system software to add a process element to a process element linked list). In at least one embodiment, a lower 16 bits of a process handle can be an offset into a process element linked list for a process element.

[0210] FIG. 13D An exemplary accelerator integration slice 1390 is shown. In at least one embodiment, a “slice” comprises a specified portion of processing resources of accelerator integration circuit 1336. In at least one embodiment, an application is an effective address space 1382 in system memory 1314 that stores a process element 1383. In at least one embodiment, process element 1383 is stored in response to a GPU invocation 1381 from an application 1380 executing on processor 1307. In at least one embodiment, process element 1383 contains process state for corresponding application 1380. In at least one embodiment, a work descriptor (WD) 1384 contained in process element 1383 can be a single job requested by an application or can contain a pointer to a queue of jobs. In at least one embodiment, WD 1384 is a pointer to a job request queue in an application’s effective address space 1382.

[0211] In at least one embodiment, graphics acceleration module 1346 and / or individual graphics processing engines 1331(1)-1331(N) can be shared by all or a subset of processes in a system. In at least one embodiment, a process- specific programming model in which a single process owns graphics acceleration module 1346 or an individual graphics processing engine 1331. In at least one embodiment, when graphics acceleration module 1346 is owned by a single process, a hypervisor initializes accelerator integration circuit 1336 for the owned partition, and an operating system initializes accelerator integration circuit 1336 for the owned process when graphics acceleration module 1346 is assigned.

[0212] In at least one embodiment, a process-specific programming model is implementation-specific. In at least one embodiment, in this model, a single process owns graphics acceleration module 1346 or an individual graphics processing engine 1331. In at least one embodiment, when graphics acceleration module 1346 is owned by a single process, a hypervisor initializes accelerator integration circuit 1336 for the owned partition, and an operating system initializes accelerator integration circuit 1336 for the owned process when graphics acceleration module 1346 is assigned.

[0213] In at least one embodiment, in operation, a WD fetch unit 1391 in accelerator integration slice 1390 fetches a next WD 1384, which includes an indication of work to be completed by one or more graphics processing engines of graphics acceleration module 1346. In at least one embodiment, data from WD 1384 can be stored in registers 1345 and used by MMU 1339, interrupt management circuit 1347, and / or context management circuit 1348, as illustrated. For example, one embodiment of MMU 1339 includes segment / page walk circuitry to access segment / page tables 1386 within OS virtual address space 1385. In at least one embodiment, interrupt management circuit 1347 can handle interrupt events 1392 received from graphics acceleration module 1346. In at least one embodiment, effective addresses 1393 generated by graphics processing engines 1331(1)-1331(N) are translated to real addresses by MMU 1339 when performing graphics operations.

[0214] In at least one embodiment, registers 1345 are replicated for each graphics processing engine 1331(1)-1331(N) and / or graphics acceleration module 1346, and can be initialized by a hypervisor or operating system. In at least one embodiment, each of these replicated registers can be included in an accelerator integration slice 1390. An example register that can be initialized by a hypervisor is illustrated in Table 1.

[0215] Table 1 - Hypervisor-Initialized Registers

[0216]

[0217]

[0218] Exemplary registers that can be initialized by the operating system are shown in Table 2.

[0219] Table 2 - Registers for operating system initialization

[0220]

[0221] In at least one embodiment, each WD 1384 is specific to a particular graphics acceleration module 1346 and / or graphics processing engine 1331(1)-1331(N). In at least one embodiment, it contains all information needed for a graphics processing engine 1331(1)-1331(N) to complete work, or it can be a pointer to a memory location where an application has set up a command queue of work to be completed.

[0222] FIG. 13E Additional details of one exemplary embodiment of a shared model are shown. This embodiment includes a hypervisor real address space 1398 in which a list of process elements 1399 is stored. In at least one embodiment, hypervisor real address space 1398 is accessible via hypervisor 1396, which virtualizes graphics acceleration module engines for operating system 1395.

[0223] In at least one embodiment, a shared programming model allows all processes or a subset of processes from all partitions or a subset of partitions in a system to use a graphics acceleration module 1346. In at least one embodiment, there are two programming models in which a graphics acceleration module 1346 is shared by multiple processes and partitions, namely time-sliced sharing and graphics-directed sharing.

[0224] In at least one embodiment, in this model, a system hypervisor 1396 owns a graphics acceleration module 1346 and makes its functionality available to all operating systems 1395. In at least one embodiment, for a graphics acceleration module 1346 to support virtualization by a system hypervisor 1396, it can adhere to certain requirements, such as (1) an application’s job request must be autonomous (i.e., no state needs to be kept between jobs), or the graphics acceleration module 1346 must provide a context save and restore mechanism, (2) the graphics acceleration module 1346 guarantees that an application’s job request completes within a specified amount of time, including any translation faults, or the graphics acceleration module 1346 provides the ability to preempt job processing, and (3) when operating in a directed sharing programming model, the graphics acceleration module 1346 must ensure fairness between processes.

[0225] In at least one embodiment, application 1380 is required to use a graphics acceleration module type, a work descriptor (WD), an authority mask register (AMR) value, and a context save / restore area pointer (CSRP) for an operating system 1395 system call. In at least one embodiment, the graphics acceleration module type describes a target acceleration function for the system call. In at least one embodiment, the graphics acceleration module type can be a system-specific value. In at least one embodiment, the WD is formatted specifically for a graphics acceleration module 1346 and can take the form of a graphics acceleration module 1346 command, a valid address pointer to a user-defined structure, a valid address pointer to a command queue, or the form of any other data structure describing work to be done by a graphics acceleration module 1346.

[0226] In at least one embodiment, the AMR value is the AMR state for the current process. In at least one embodiment, the value passed to the operating system is similar to how an application program sets the AMR. In at least one embodiment, if an accelerator integration circuit 1336 (not shown) and graphics acceleration module 1346 implementation does not support a user authority mask override register (UAMOR), then the operating system can apply the current UAMOR value to the AMR value before passing the AMR in a hypervisor call. In at least one embodiment, the hypervisor 1396 can selectively apply the current authority mask override register (AMOR) value before placing the AMR in the process element 1383. In at least one embodiment, the CSRP is one of registers 1345 that contains a valid address of an area in application’s effective address space 1382 for a graphics acceleration module 1346 to save and restore context state. In at least one embodiment, this pointer is optional if there is no need to save state between jobs or when a job is preempted. In at least one embodiment, the context save / restore area can be a fixed system memory.

[0227] Upon receiving the system call, operating system 1395 can verify that application 1380 has registered and is granted authority to use graphics acceleration module 1346. Operating system 1395 then uses the information shown in Table 3 to call hypervisor 1396, in at least one embodiment.

[0228] Table 3 - Hypervisor Call Parameters from Operating System

[0229]

[0230]

[0231] In at least one embodiment, upon receiving a hypervisor call, the hypervisor 1396 verifies that the operating system 1395 has been registered and granted permission to use the graphics acceleration module 1346. Then, in at least one embodiment, the hypervisor 1396 adds the process element 1383 to a linked list of process elements of the corresponding graphics acceleration module 1346 type. In at least one embodiment, the process element may include the information shown in Table 4.

[0232] Table 4 – Process Element Information

[0233]

[0234] In at least one embodiment, the hypervisor initializes multiple accelerator integration slice 1390 registers 1345.

[0235] like FIG. 13F As shown, in at least one embodiment, a unified memory is used, which is addressable via a common virtual memory address space for accessing physical processor memories 1301(1)-1301(N) and GPU memories 1320(1)-1320(N). In this implementation, operations performed on GPUs 1310(1)-1310(N) utilize the same virtual / effective memory address space to access processor memories 1301(1)-1301(M) and vice versa, thereby simplifying programmability. In at least one embodiment, a first portion of the virtual / effective address space is allocated to processor memory 1301(1), a second portion to second processor memory 1301(N), a third portion to GPU memory 1320(1), and so on. In at least one embodiment, the entire virtual / effective memory space (sometimes referred to as the effective address space) is thus distributed across each of processor memories 1301 and GPU memories 1320, thereby allowing any processor or GPU to access that memory using a virtual address mapped to any physical memory.

[0236] In at least one embodiment, the bias / coherence management circuitry 1394A-1394E within one or more MMUs 1339A-1339E ensures cache coherence between one or more host processors (e.g., 1305) and the cache of the GPU 1310, and implements biasing techniques to indicate the physical memory in which certain types of data should be stored. In at least one embodiment, although in FIG. 13F Several instances of bias / coherence management circuits 1394A-1394E are shown, but bias / coherence circuits can be implemented within the MMU of one or more host processors 1305 and / or within the accelerator integrated circuit 1336.

[0237] One embodiment allows GPU memory 1320 to be mapped as part of system memory and accessed using shared virtual memory (SVM) techniques, but without suffering the performance penalties associated with full system cache coherency. In at least one embodiment, the ability for GPU memory 1320 to be accessed as system memory without the heavy cache coherency overhead provides a favorable operating environment for GPU offload. In at least one embodiment, this arrangement allows software of host processor 1305 to set operands and access computation results without the overhead of traditional I / O DMA data copies. In at least one embodiment, such traditional copies include driver calls, interrupts, and memory mapped I / O (MMIO) accesses, which are less efficient than simple memory accesses. In at least one embodiment, the ability to access GPU memory 1320 without cache coherency overhead can be critical to the execution time of offloaded computations. In at least one embodiment, for example, with heavy streaming write memory traffic, cache coherency overhead can significantly reduce the effective write bandwidth seen by GPU 1310. In at least one embodiment, the efficiency of operand setup, the efficiency of result access, and the efficiency of GPU computation can play a role in determining the effectiveness of GPU offload.

[0238] In at least one embodiment, the selection of GPU bias and host processor bias is driven by a bias tracker data structure. In at least one embodiment, for example, a bias table can be used, which can be a page-granularity structure (e.g., controlling at the granularity of a memory page), including 1 or 2 bits per GPU-attached memory page. In at least one embodiment, with or without a bias cache in GPU 1310 (e.g., to cache frequently / recently used entries of the bias table), the bias table can be implemented in a stolen memory range of one or more GPU memories 1320. Alternatively, in at least one embodiment, the entire bias table can be maintained within the GPU.

[0239] In at least one embodiment, prior to actually accessing GPU memory, a bias table entry associated with each access to GPU-attached memory 1320 is accessed, causing the following operations. In at least one embodiment, local requests from GPU 1310 that find their pages in GPU bias are forwarded directly to corresponding GPU memory 1320. In at least one embodiment, local requests from GPU that find their pages in host bias are forwarded to processor 1305 (e.g., over a high-speed link as described herein). In at least one embodiment, requests from processor 1305 that find requested pages in host processor bias complete similar to a normal memory read. Alternatively, requests that point to GPU bias pages can be forwarded to GPU 1310. In at least one embodiment, if GPU is not currently using a page, GPU can migrate the page to host processor bias. In at least one embodiment, bias state of a page can be changed by software-based mechanisms, hardware-assisted software-based mechanisms, or in the case of a limited set, purely hardware-based mechanisms.

[0240] In at least one embodiment, a mechanism for changing bias state employs an API call (e.g., OpenCL) that in turn invokes a device driver of a GPU that in turn sends a message (or causes a command descriptor to be enqueued) to a GPU, directing the GPU to change bias state and, in certain migrations, to perform a cache flush operation in a host. In at least one embodiment, a cache flush operation is used for migration from host processor 1305 bias to GPU bias, but not for the reverse migration.

[0241] In at least one embodiment, cache coherency is maintained by temporarily rendering GPU bias pages that host processor 1305 cannot cache. In at least one embodiment, to access these pages, processor 1305 can request access from GPU 1310, which can or can not grant access immediately. Thus, in at least one embodiment, to reduce communication between processor 1305 and GPU 1310, it is beneficial to ensure that GPU bias pages are pages that are needed by GPU and not by host processor 1305, and vice versa.

[0242] One or more hardware structures 615 are used to perform one or more embodiments. Details regarding one or more hardware structures 615 can be found in this document in connection with FIG. 6A and / or FIG. 6B Details regarding one or more hardware structures 615 are provided.

[0243] FIG. 14Exemplary integrated circuits and associated graphics processors in accordance with various embodiments described herein are shown, which can be fabricated using one or more IP cores. In addition to the illustrated, other logic and circuitry can also be included, including additional graphics processors / cores, peripheral interface controllers or general purpose processor cores.

[0244] FIG. 14 is a block diagram illustrating an exemplary system on a chip integrated circuit 1400 that can be fabricated using one or more IP cores, in accordance with at least one embodiment. In at least one embodiment, integrated circuit 1400 includes one or more application processor(s) 1405 (e.g., CPUs), at least one graphics processor 1410, and can additionally include an image processor 1415 and / or a video processor 1420, any of which can be a modular IP core. In at least one embodiment, integrated circuit 1400 includes peripheral or bus logic including a USB controller 1425, a UART controller 1430, an SPI / SDIO controller 1435, and an I2S / I2C controller 1440. In at least one embodiment, integrated circuit 1400 can include a display device 1445 coupled to one or more of a high-definition multimedia interface (HDMI) controller 1450 and a mobile industry processor interface (MIPI) display controller 1455. In at least one embodiment, storage can be provided by a flash memory subsystem 1460 including flash memory and a flash memory controller. In at least one embodiment, memory interface can be provided via a memory controller 1465 for access to SDRAM or SRAM memory devices. In at least one embodiment, some integrated circuits also include an embedded security engine 1470. 2 S / I 2 Ccontroller 1440. In at least one embodiment, integrated circuit 1400 can include a display device 1445 coupled to one or more of a high-definition multimedia interface (HDMI) controller 1450 and a mobile industry processor interface (MIPI) display controller 1455. In at least one embodiment, storage can be provided by a flash memory subsystem 1460 including flash memory and a flash memory controller. In at least one embodiment, memory interface can be provided via a memory controller 1465 for access to SDRAM or SRAM memory devices. In at least one embodiment, some integrated circuits also include an embedded security engine 1470.

[0245] Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 can be used in FIG. 6A and / or FIG. 6B Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 can be used in integrated circuit 1400 to infer or predict operations based, at least in part, on weight parameters calculated using neural network training operations, neural network functions and / or architectures, or neural network use cases described herein.

[0246] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used in conjunction with FIG. 14characteristics are used in combination, and can be configured to receive sensor inputs from multiple sensors, and can be trained to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor inputs to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor inputs can be correlated to different classes of cooling demand for each different sensor input. In at least one embodiment, a new sensor input categorized in such different classes of sensor input can be indicative of a cooling demand, or a change thereof.

[0247] FIGS. 15A-15B Exemplary integrated circuits and associated graphics processors, in accordance with various embodiments described herein, can be fabricated using one or more IP cores. In addition to the illustrated, other logic and circuitry can be included, including additional graphics processors / cores, peripheral interface controllers, or general purpose processor cores.

[0248] FIGS. 15A-15B is a block diagram illustrating an exemplary graphics processor used within a SoC, in accordance with embodiments described herein. FIG. 15A Exemplary graphics processor 1510 of a system on a chip integrated circuit, in accordance with at least one embodiment, is shown and can be fabricated using one or more IP cores. FIG. 15B Additional exemplary graphics processor 1540 of a system on a chip integrated circuit, in accordance with at least one embodiment, is shown and can be fabricated using one or more IP cores. In at least one embodiment, FIG. 15A Graphics processor 1510 is a low power graphics processor core. In at least one embodiment, FIG. 15B Graphics processor 1540 is a higher performance graphics processor core. In at least one embodiment, each graphics processor 1510, 1540 can be a FIG. 14 Variants of graphics processor 1410.

[0249] In at least one embodiment, graphics processor 1510 includes a vertex processor 1505 and one or more fragment processor(s) 1515A-1515N (e.g., 1515A, 1515B, 1515C, 1515D, through 1515N-1, and 1515N). In at least one embodiment, graphics processor 1510 can execute different shader programs via separate logic for vertex processing and / or for fragment / pixel processing, where some shader programs mayonly be used by one of these types of processing. In at least one embodiment, vertex processor 1505 is optimized to execute operations on vertex data that frequently process vertex data in large batches using highly parallel processing. In at least one embodiment, one or more fragment processor(s) 1515A-1515N can be optimized to execute similar shader programs as vertex processor 1505, but on a smaller number of data.

[0250] In at least one embodiment, graphics processor 1510 additionally includes one or more memory management units (MMUs) 1520A-1520B, one or more caches 1525A-1525B, and one or more circuit interconnects 1530A-1530B. In at least one embodiment, one or more MMUs 1520A-1520B provide an access mechanism between memory and one or more of a vertex processor 1505, a fragment processor(s) 1515A-1515N, and / or a circuit interconnect 1530A-1530B, in at least one embodiment, one or more MMUs 1520A-1520B can be synchronized with one or more MMUs within one or more application processor(s) 1405, image processors 1415, and / or video processors 1420 within a system on a chip (SoC) so that each processor 1405-1420 can participate in a common shared or unified virtual memory system. FIG. 14 In at least one embodiment, one or more circuit interconnects 1530A-1530B enable graphics processor 1510 to interface with other IP cores within a SoC, either via an internal bus, as shown, or via a direct connection.

[0251] In at least one embodiment, graphics processor 1540 includes a ring interconnect 1545, one or more general processing clusters (GPCs) 1550A-1550B, and / or one or more rendering endpoints 1555A-1555B. In at least one embodiment, ring interconnect 1545 includes circuitry to implement a high-speed clock bus for implementing high-speed communication. In at least one embodiment, one or more GPCs 1550A-1550B each include a pipeline to execute instructions and perform operations on data and / or one or more memory subsystems to store / retrieve data used while operating on data. In at least one embodiment, one or more rendering endpoints 1555A-1555B can include dedicated circuitry to perform rendering operations in a graphics pipeline. In at least one embodiment, one or more GPCs 1550A-1550B implement a single-program multiple-data (SPMD) approach to processing, to allow each processor to run the same program. In at least one embodiment, each processor 1550A-1550B reads the same program but executes it against different data.FIG. 15B one or more shader cores 1555A-1555N (e.g., 1555A, 1555B, 1555C, 1555D, 1555E, 1555F through 1555N-1, and 1555N) are shown that provide a unified shader core architecture in which a single core or type or core can execute all types of programmable shader code including shader program code to implement a vertex shader, a fragment shader, and / or a compute shader. In at least one embodiment, the number of shader cores can vary. In at least one embodiment, graphics processor 1540 includes an inter-core task manager 1545 that acts as a thread dispatcher to divide workloads between the one or more shader cores 1555A-1555N and a tiling unit 1558 to accelerate tiling operations for tile-based rendering in which a rendering operation is subdivided in image space, e.g., to exploit spatial locality or optimize use of an on-chip cache.

[0252] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used in conjunction with features of FIG. 15A , FIG. 15B , and can be configured to receive sensor inputs from multiple sensors and can be trained to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor inputs to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor inputs can be correlated with different classes of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such a different class of sensor inputs can be indicative of a cooling demand, or a change therein.

[0253] FIGS. 16A-16B Additional exemplary graphics processor logic in accordance with the embodiments described herein is shown. In at least one embodiment, graphics processor 1410 can include graphics core 1600, which can be a unified shader core 1555A-1555N as shown in FIG. 16A FIG. 14 In at least one embodiment, graphics processor 1410 can include graphics core 1600, which can be a unified shader core 1555A-1555N as shown in FIG. 15B FIG. 16B A highly parallel general purpose graphics processing unit (“GPGPU”) 1630 suitable for deployment on a multi-chip module is shown in at least one embodiment.

[0254] ​​In at least one embodiment, graphics core 1600 includes a shared instruction cache 1602, texture unit(s) 1618, and cache / shared memory 1620 (e.g., including LI, L2, L3, last level cache, or other cache) that are common to the execution resources within graphics core 1600. In at least one embodiment, graphics core 1600 can include a number of slices 1601 A-1601N or partitions of each core and graphics processor can include multiple instances of graphics core 1600. In at least one embodiment, each slice 1601 A-1601N refers to graphics core 1600. In at least one embodiment, slices 1601 A-1601N have sub-slices, which are part of slices 1601 A-1601N. In at least one embodiment, slices 1601 A-1601N are independent of each other or dependent upon each other. In at least one embodiment, slices 1601 A-1601N can include support logic including a local instruction cache 1604A-1604N, a thread scheduler (sequencer) 1606A-1606N, a thread dispatcher 1608A-1608N, and a set of registers 1610A-1610N. In at least one embodiment, slices 1601 A-1601N can include a set of additional functional units (AFUs 1612A-1612N), floating point units (FPUs 1614A-1614N), integer arithmetic logic units (ALUs 1616A-1616N), address computation units (ACUs 1613A-1613N), double precision floating point units (DPFPUs 1615A-1615N), and matrix processing units (MPUs 1617A-1617N).

[0255] In at least one embodiment, each slice 1601A-1601N includes one or more engines for floating point and integer vector operations and one or more engines for accelerating convolutions and matrix operations in AI, machine learning, or big data set workloads. In at least one embodiment, one or more slices 1601A-1601N include one or more vector engines for computing vectors (e.g., mathematical operations on vectors). In at least one embodiment, vector engines can compute vector operations in 16-bit floating point (also referred to as “FP16”), 32-bit floating point (also referred to as “FP32”), or 64-bit floating point (also referred to as “FP64”). In at least one embodiment, one or more slices 1601A-1601N include 16 vector engines paired with 16 matrix math units to compute matrix / tensor operations, where vector engines and math units are shown through matrix expansion. In at least one embodiment, slices are made to a specified portion of processing resources of a processing unit (e.g., 16 cores and a ray-tracing unit or 8 cores), a thread scheduler, an additional functional unit of a thread scheduler and processor. In at least one embodiment, graphics core 1600 includes one or more matrix engines to compute matrix operations, for example, when computing tensor operations.

[0256] In at least one embodiment, one or more slices 1601A-1601N include one or more ray-tracing units to compute ray-tracing operations (e.g., 16 ray-tracing unit slices 1601A-1601N per slice). In at least one embodiment, ray-tracing units compute ray traversal, triangle intersection, bounding volume intersection, or other ray-tracing operations.

[0257] In at least one embodiment, one or more slices 1601A-1601N include media slices that encode, decode, and / or transcode data; scale and / or format convert data; and / or perform video quality operations on video data.

[0258] In at least one embodiment, one or more slices 1601A-1601N are linked to an L2 cache and memory structure, a link connector, a high bandwidth memory (HBM) (e.g., HBM2e, HDMI3) stack, and a media engine. In at least one embodiment, one or more slices 1601A-1601N include a plurality of cores (e.g., 16 cores) and a plurality of ray-tracing units (e.g., 16) paired with each core. In at least one embodiment, one or more slices 1601A-1601N have one or more LI caches. In at least one embodiment, one or more slices 1601A-1601N include one or more vector engines; one or more instruction caches to store instructions; one or more LI caches to cache data; one or more shared local memories (SLMs) to store, e.g., data corresponding to instructions; one or more samplers to sample data; one or more ray-tracing units to perform ray-tracing operations; one or more geometries to perform operations in a geometry pipeline and / or apply geometric transformations to vertices or polygons; one or more rasterizers to describe an image in a vector graphics format (e.g., shapes) and convert it to a raster image (e.g., a series of pixels, dots, or lines that, when displayed together, create an image represented by the shapes); one or more hierarchical z-buffers (Hiz) to buffer data; and / or one or more pixel back-ends. In at least one embodiment, slices 1601A-1601N include a memory structure, e.g., an L2 cache.

[0259] In at least one embodiment, FPUs 1614A-1614N can perform single-precision (32-bit) and half-precision (16-bit) floating point operations, while DPFPUs 1615A-1615N perform double-precision (64-bit) floating point operations. In at least one embodiment, ALUs 1616A-1616N can perform variable precision integer operations at 8-bit, 16-bit, and 32-bit precision, and can be configured for mixed precision operations. In at least one embodiment, MPUs 1617A-1617N can also be configured for mixed precision matrix operations, including half-precision floating point operations and 8-bit integer operations. In at least one embodiment, MPUs 1617A-1617N can perform various matrix operations to accelerate machine learning application frameworks, including enabling support for accelerated general matrix to matrix multiplication (GEMM). In at least one embodiment, AFUs 1612A-1612N can perform additional logical operations not supported by floating or integer units, including trigonometric operations (e.g., sine, cosine). Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Inference and / or training logic 615 can be used in a variety of contexts including as part of a process that is trained as part of one or more embodiments. In at least one embodiment, inference and / or training logic 615 can be used in the context of a neural network, such as those described herein. FIG. 6A and / orFIG. 6B Details regarding inference and / or training logic 615 are provided. In at least one embodiment, inference and / or training logic 615 can be used in graphics core 1600 for inferencing or predicting operations based, at least in part, on weight parameters calculated using neural network training operations, neural network functions and / or architectures, or neural network use cases described herein.

[0260] In at least one embodiment, graphics core 1600 includes an interconnect and link structure sublayer attached to a switch and GPU-GPU bridge that enables multiple graphics processors 1600 (e.g., 8) to interconnect with one another in a non-tied configuration through load / store units (LSUs), data transfer units, and synchronization semantics across multiple graphics processors 1600. In at least one embodiment, interconnect includes a standardized interconnect (e.g., PCIe) or some combination thereof.

[0261] In at least one embodiment, graphics core 1600 includes multiple tiles. In at least one embodiment, a tile is a separate die or one or more dies where a separate die can be connected with an interconnect (e.g., an embedded multi-die interconnect bridge (EMIB)). In at least one embodiment, graphics core 1600 includes a compute tile, a memory tile (e.g., where memory tile is exclusively accessible by different tile or different chip set such as a Rambo tile), a substrate tile, a base tile, an HMB tile, a link tile, and an EMIB tile, where all tiles together are packaged as part of a GPU in graphics core 1600. In at least one embodiment, graphics core 1600 can include multiple tiles in a single package (also referred to as a “multi-tile package”). In at least one embodiment, a compute tile can have 8 graphics cores 1600, L1 cache; and a base tile can have a host interface with PCIe 5.0, HBM2e, MDFI, and EMIB, a link tile with 8 links, 8 ports with embedded switch. In at least one embodiment, tiles are connected with face-to-face (F2F) chip-on-chip bonding with fine pitch 36-micron microbumps (e.g., copper pillars). In at least one embodiment, graphics core 1600 includes a memory structure including memory and is a tile that is accessible by multiple tiles. In at least one embodiment, graphics core 1600 stores, accesses, or loads its own hardware context into memory, where a hardware context is a set of data loaded from registers prior to process resumption and where a hardware context can indicate a state of hardware (e.g., a state of a GPU).

[0262] In at least one embodiment, graphics core 1600 includes a serializer / deserializer (SERDES) circuit that converts a serial data stream into a parallel data stream, or converts a parallel data stream into a serial data stream.

[0263] In at least one embodiment, graphics core 1600 includes a high-speed coherent unified fabric (GPU-to-GPU), load / store units, batch data transfer and synchronization semantics, and GPUs connected through embedded switches, where GPU-GPU bridges are controlled by a controller.

[0264] In at least one embodiment, graphics core 1600 executes an API that abstracts hardware of graphics core 1600 and uses instructions to access libraries to perform mathematical operations (e.g., a mathematical kernel library), deep neural network operations (e.g., a deep neural network library), vector operations, collective communications, thread building blocks, video processing, data analytics libraries, and / or ray tracing operations.

[0265] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used in conjunction with features of FIG. 16A and can be configured to receive sensor inputs from a plurality of sensors and can be trained to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor inputs to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor inputs can be correlated to different classes of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such different classes of sensor input can be indicative of a cooling demand, or a change therein.

[0266] FIG. 16BA general-purpose processing unit (GPGPU) 1630 is illustrated in at least one embodiment, which can be configured to enable highly parallel computational operations to be performed by an array of graphics processing units. In at least one embodiment, the GPGPU 1630 can be directly linked to other instances of the GPGPU 1630 to create a multi-GPU cluster to improve the training speed for deep neural networks. In at least one embodiment, the GPGPU 1630 includes a host interface 1632 for establishing a connection with a host processor. In at least one embodiment, the host interface 1632 is a PCI Express interface. In at least one embodiment, the host interface 1632 may be a vendor-specific communication interface or communication structure. In at least one embodiment, the GPGPU 1630 receives commands from the host processor and uses a global scheduler 1634 (which may be referred to as a thread sequencer and / or asynchronous computing engine) to allocate the execution threads associated with those commands to a set of computing clusters 1636A-1636H. In at least one embodiment, the computing clusters 1636A-1636H share a cache memory 1638. In at least one embodiment, cache memory 1638 can be used as a higher-level cache within the cache memory of computing clusters 1636A-1636H.

[0267] In at least one embodiment, the GPGPU 1630 includes memories 1644A-1644B coupled to the compute cluster 1636A-1636H via a set of memory controllers 1642A-1642B (e.g., one or more controllers of HBM2e). In at least one embodiment, memories 1644A-1644B may include various types of memory devices, including dynamic random access memory (DRAM) or graphics random access memory, such as synchronous graphics random access memory (SGRAM), which includes graphics double data rate (GDDR) memory.

[0268] In at least one embodiment, each of the computing clusters 1636A-1636H includes a set of graphics cores, such as FIG. 16A The graphics core 1600 may include various types of integer and floating-point logic units that can perform computational operations over a range of precision suitable for machine learning computations. For example, in at least one embodiment, at least a subset of the floating-point units in each computing cluster 1636A-1636H may be configured to perform 16-bit or 32-bit floating-point operations, while different subsets of the floating-point units may be configured to perform 64-bit floating-point operations.

[0269] In at least one embodiment, multiple instances of GPGPU 1630 can be configured to operate as a compute cluster. In at least one embodiment, communication for synchronization and data exchange between compute clusters 1636A-1636H varies between embodiments. In at least one embodiment, multiple instances of GPGPU 1630 communicate via host interface 1632. In at least one embodiment, GPGPU 1630 includes I / O hub 1639 which couples GPGPU 1630 with GPU links 1640 which enable direct connections to other instances of GPGPU 1630. In at least one embodiment, GPU links 1640 couple to a specialized GPU-to-GPU bridge that enables communication and synchronization between multiple instances of GPGPU 1630. In at least one embodiment, GPU links 1640 couple with a high-speed interconnect to transmit and receive data to other GPGPUs or parallel processors. In at least one embodiment, multiple instances of GPGPU 1630 are located in separate data processing systems and communicate via a network device accessible via host interface 1632. In at least one embodiment, GPU links 1640 can be configured to enable connections to a host processor in addition to or as an alternative to host interface 1632.

[0270] In at least one embodiment, GPGPU 1630 can be configured to train neural networks. In at least one embodiment, GPGPU 1630 can be used within an inferencing platform. In at least one embodiment, GPGPU 1630 can include fewer compute clusters 1636A-1636H relative to when GPGPU 1630 is used to train neural networks. In at least one embodiment, memory technology associated with memory 1644A-1644B can vary between inferencing and training configurations, with higher bandwidth memory technology dedicated to training configurations. In at least one embodiment, an inferencing configuration of GPGPU 1630 can support inferencing specific instructions. For example, in at least one embodiment, an inferencing configuration can provide support for one or more 8-bit integer dot product instructions that can be used during inferencing operations of deployed neural networks.

[0271] Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and 6M. FIG. 6A and / or FIG. 6BDetails regarding the inference and / or training logic 615 are provided. In at least one embodiment, the inference and / or training logic 615 can be used in GPGPU 1630 for inferencing or predicting operations based, at least in part, on weight parameters calculated using neural network training operations described herein.

[0272] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used in conjunction with features of FIG. 16B and can be configured to receive sensor inputs from multiple sensors and can be trained to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor inputs to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can infer changes in cooling demand. In at least one embodiment, sensor inputs can be correlated with different classes of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such a different class of sensor inputs can be indicative of cooling demand, or a change therein.

[0273] FIG. 17 is a block diagram illustrating a computing system 1700, in accordance with at least one embodiment. In at least one embodiment, computing system 1700 includes a processing subsystem 1701 with one or more processor(s) 1702 and system memory 1704, communicating via an interconnection path 1705 that can include a memory hub 1705. In at least one embodiment, memory hub 1705 can be a separate component coupled with one or more processors 1702 via individual communication links 1707A, 1707B, 1707C, 1707D, 1707E, 1707F. In at least one embodiment, memory hub 1705 can be integrated into one or more processors 1702 or can be a stand-alone component.

[0274] In at least one embodiment, processing subsystem 1701 includes one or more parallel processors 1712 coupled to memory hub 1705 via a bus or other communication link 1713. In at least one embodiment, communication link 1713 can use one of any number of standard communication technologies or protocols, including but not limited to PCI Express, or any other communication technology or protocol that is suitable for the purposes of communicating between processing subsystem 1701 and memory hub 1705. In at least one embodiment, one or more parallel processors 1712 form a computationally intensive, parallel, or vector processing system that can include a large number of processing cores and / or thread units, such as an integrated

[0275] In at least one embodiment, system storage unit 1714 can connect to I / O hub 1707 to provide storage mechanisms for computing system 1700. In at least one embodiment, I / O switch 1716 can be used to provide an interface mechanism to enable connections between I / O hub 1707 and other components, such as network adapter 1718 and / or wireless network adapter 1719 that can be integrated on platform, as well as various other devices that can be added via one or more add-in devices 1720. In at least one embodiment, network adapter 1718 can be an Ethernet adapter or another wired

[0276] In at least one embodiment, computing system 1700 can include other components not explicitly shown, such as a USB or other port connection, an optical storage device, a video capture device, etc. that can also be connected to I / O hub 1707. In at least one embodiment, communication paths between various components of computing system 1700 can be implemented using any suitable protocols, such as those described above, including PCI-based protocols (e.g., PCI-Express), or other bus or point-to-point communication interfaces and / or protocols (such as NV-Link high-speed interconnect or other interconnect protocols). FIG. 17 In at least one embodiment, communication paths between various components of computing system 1700 can be implemented using any suitable protocols, such as those described above, including PCI-based protocols (e.g., PCI-Express), or other bus or point-to-point communication interfaces and / or protocols (such as NV-Link high-speed interconnect or other interconnect protocols).

[0277] In at least one embodiment, one or more parallel processor(s) 1712 include circuitry for executing instructions to perform graphics and video processing, including for example, video output circuitry and are configured for use in a gaming, media, and communications platform such as a gaming, media, and communications platform that includes a system on a chip. In at least one embodiment, one or more parallel processor(s) 1712 include circuitry for executing instructions to perform general processing e.g., one or more of the graphics core(s) 1600 include circuitry specifically configured and / or programmed to perform general processing. In at least one embodiment, components of computing system 1700 may

[0278] Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 is used in system 1700 for inferencing or predicting operations based, at least in part, on weight parameters calculated using neural network training operations, neural network functions and / or architectures, or neural network use cases described herein. FIG. 6A Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 is used in system 1700 for inferencing or predicting operations based, at least in part, on weight parameters calculated using neural network training operations, neural network functions and / or architectures, or neural network use cases described herein. FIG. 6B Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 is used in system 1700 for inferencing or predicting operations based, at least in part, on weight parameters calculated using neural network training operations, neural network functions and / or architectures, or neural network use cases described herein. FIG. 17 Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 is used in system 1700 for inferencing or predicting operations based, at least in part, on weight parameters calculated using neural network training operations, neural network functions and / or architectures, or neural network use cases described herein.

[0279] Processor

[0280] FIG. 18A A parallel processor 1800, according to at least one embodiment, is shown in FIG. 18. In at least one embodiment, various components of parallel processor 1800 may FIG. 17 Variations of one or more parallel processor(s) 1712 are shown. In at least one embodiment, parallel processor 1800 includes one or more graphics cores 1600.

[0281] In at least one embodiment, parallel processor 1800 includes a parallel processing unit 1802. In at least one embodiment, parallel processing unit 1802 includes an I / O unit 1804 that enables communication with other devices, including other instances of parallel processing unit 1802. In at least one embodiment, I / O unit 1804 can be directly connected to the other devices. In at least one embodiment, I / O unit 1804 connects with other devices via the use of a hub or switch interface, such as memory hub 1805. In at least one embodiment, connections between memory hub 1805 and I / O unit 1804 form a communication link 1813. In at least one embodiment, I / O unit 1804 connects with a host interface 1806 and a memory crossbar 1816, where host interface 1806 receives commands directed to the processing operations and memory crossbar 1816 receives commands directed to memory operations.

[0282] In at least one embodiment, when host interface 1806 receives a command buffer via I / O unit 1804, host interface 1806 can direct the work operations for performing those commands to front end 1808. In at least one embodiment, front end 1808 couples with a scheduler 1810 (which can be referred to as a sequencer) that is configured to assign commands or other work items to a processing cluster array 1812. In at least one embodiment, scheduler 1810 ensures that processing cluster array 1812 is correctly configured and in an active state before tasks are assigned to clusters within processing cluster array 1812. In at least one embodiment, scheduler 1810 is implemented via firmware logic executing on a microcontroller. In at least one embodiment, microcontroller implemented scheduler 1810 can be configured to perform complex scheduling and work distribution operations with coarse and fine grain granularity, enabling low-latency pre-emption and context switching for threads executing on processing cluster array 1812. In at least one embodiment, host software can prove a workload for scheduling on processing cluster array 1812 via one of multiple graphics processing paths. In at least one embodiment, workload can then be automatically distributed by scheduler 1810 logic within microcontroller including scheduler 1810 logic on processing cluster array 1812.

[0283] In at least one embodiment, processing cluster array 1812 can include up to “N” processing clusters (e.g., cluster 1814A, cluster 1814B, through cluster 1814N), where “N” represents a positive integer (which can be different than the integer “N” used in other Figures). In at least one embodiment, each cluster 1814A-1814N of processing cluster array 1812 can execute a large number of concurrent threads. In at least one embodiment, scheduler 1810 can allocate work to clusters 1814A-1814N of processing cluster array 1812 using various scheduling and / or work distribution algorithms, which can be determined at least in part by compiler logic when compiling program logic configured for execution by processing cluster array 1812. In at least one embodiment, different clusters 1814A-1814N of processing cluster array 1812 can be allocated for processing different types of programs or for performing different types of computations.

[0284] In at least one embodiment, processing cluster array 1812 can be configured to perform a variety of types of parallel processing operations. In at least one embodiment, processing cluster array 1812 is configured to perform general-purpose parallel compute operations. For example, in at least one embodiment, processing cluster array 1812 can include logic to perform processing tasks comprising filtering of video and / or audio data, performing modeling operations, including physics operations, and performing data transformations.

[0285] In at least one embodiment, processing cluster array 1812 is configured to perform parallel graphics processing operations. In at least one embodiment, processing cluster array 1812 can include additional logic to support the performance of such graphics processing operations including, but not limited to, texture sampling logic to perform texture operations for three-dimensional (3D) graphics, and surface rendering logic and other vertex processing logic. In at least one embodiment, processing cluster array 1812 can be configured to execute shader programs, such as, but not limited to, vertex shaders, tessellation shaders, geometry shaders, and pixel (or fragment) shaders, in relation to graphics processing. In at least one embodiment, parallel processing unit 1802 can transfer data from system memory for processing via I / O unit 1804. In at least one embodiment, during processing, results can be written to on-chip memory (e.g., parallel processor memory 1822) and then written back to system memory.

[0286] In at least one embodiment, when parallel processing unit 1802 is used to perform graphics processing, scheduler 1810 can be configured to divide the processing workload into approximately equal sized tasks to better enable distribution of graphics processing operations across multiple clusters 1814A-1814N in processing cluster array 1812. In at least one embodiment, different portions of processing cluster array 1812 can be configured to perform different types of processing. For example, in at least one embodiment, a first portion can be configured to perform vertex shading and topology generation, a second portion can be configured to perform surface

[0287] In at least one embodiment, processing cluster array 1812 can receive processing tasks to be executed from scheduler 1810, which receives commands defining the processing tasks from front end 1808. In at least one embodiment, processing tasks can comprise indices of data to be processed, e.g., surface (patch) data, primitive data, vertex data, and / or pixel data, as well as state parameters and commands (e.g., what programs to execute) that control how the data is to be processed. In at least one embodiment, scheduler 1810 can be configured to fetch the indices corresponding to a task, or can receive the indices from front end 1808. In at least one embodiment, front end 1808 can be configured to ensure that processing cluster array 1812 is configured in an effective state before a workload initiated by an incoming command buffer (e.g., a batch-buffer, a push buffer, etc.) is launched.

[0288] In at least one embodiment, each of one or more instances of parallel processing unit 1802 can be coupled to a parallel processor memory 1822. In at least one embodiment, parallel processor memory 1822 can be accessed by parallel processing unit 1802, either by one or more of its processing clusters 1812, its I / O units 1804, or by a memory crossbar 1816 that is coupled to both. In at least one embodiment, memory crossbar 1816 can be used to facilitate communication between each of processing clusters 1812 and memory 1822. In at least one embodiment, a copy of data written to a memory location within memory 1822 can be read by all processing clusters 1812, thereby allowing them to act in unison.

[0289] In at least one embodiment, memory units 1824A-1824N can include various types of memory devices including dynamic random access memory (DRAM) or graphics random access memory, such as synchronous graphics random access memory (SGRAM), including graphics double data rate (GDDR) memory. In at least one embodiment, memory units 1824A-1824N can also include 3D stacked memory, including but not limited to high bandwidth memory (HBM, HBM2e, or HDM3). In at least one embodiment, render targets such as frame buffers or texture maps can be stored across memory units 1824A-1824N, allowing partition units 1820A-1820N to write portions of each render target in parallel for efficient use of available bandwidth of parallel processor memory 1822. In at least one embodiment, local instances of parallel processor memory 1822 can be excluded from a unified memory design that utilizes system memory along with local cache memory.

[0290] In at least one embodiment, any of clusters 1814A-1814N in cluster array 1812 can process data to be written into any of memory units 1824A-1824N within parallel processor memory 1822. In at least one embodiment, memory crossbar 1816 can be configured to transmit outputs of each cluster 1814A-1814N to any partition unit 1820A-1820N or another cluster 1814A-1814N, which can perform additional processing operations on the outputs. In at least one embodiment, each cluster 1814A-1814N can communicate with memory interface 1818 through memory crossbar 1816 to read from or write to various external memory devices. In at least one embodiment, memory crossbar 1816 has a connection for communicating with I / O unit 1804 to memory interface 1818, as well as to a local instance of parallel processor memory 1822, which enables processing units within the different processing clusters 1814A-1814N to communicate with system memory or other memories not local to the parallel processing units 1802. In at least one embodiment, memory crossbar 1816 can use virtual channels to separate traffic flows between clusters 1814A-1814N and partition units 1820A-1820N.

[0291] In at least one embodiment, multiple instances of parallel processing unit 1802 can be provided on a single add-in card, or multiple add-in cards can be interconnected. In at least one embodiment, different instances of parallel processing unit 1802 can be configured to operate in coordination with each other to enable parallel processing operations. For example, in at least one embodiment, some instances of parallel processing unit 1802 can be configured to perform physics calculations for a game, simulations, machine learning training, etc., while others instances can be configured to generate graphics, perform physics simulations, etc.

[0292] FIG. 18B is a block diagram of a partition unit 1820, in accordance with at least one embodiment. In at least one embodiment, partition unit 1820 is a FIG. 18Aone of partition units 1820A-1820N. In at least one embodiment, partition unit 1820 includes an L2 cache 1821, a frame buffer interface 1825, and a ROP 1826 (Raster Operations Unit). In at least one embodiment, L2 cache 1821 is a read / write cache that is configured to perform load and store operations received from memory crossbar 1816 and ROP 1826. In at least one embodiment, L2 cache 1821 outputs read misses and urgent write-backs to frame buffer interface 1825 for processing. In at least one embodiment, updates can also be sent to frame buffer via frame buffer interface 1825 for processing. In at least one embodiment, frame buffer interface 1825 interfaces with one of memory units 1824A-1824N (e.g., within parallel processor memory 1822) in parallel processor memory. FIG. 18A

[0293] In at least one embodiment, ROP 1826 is a processing unit that performs raster operations including, for example, fill, line, polygon, and / or surface rendering. In at least one embodiment, ROP 1826 is analogous to a graphics processor that performs these operations with assistance from one or more parallel processor(s) 1800. In at least one embodiment, ROP 1826 outputs elementary primitives, which are completed primitives which can be textured and / or lit as determined by one or more parallel processor(s) 1800.

[0294] In at least one embodiment, ROP 1826 includes, for example, one or more surface engines to process 3D surfaces. In at least one embodiment, ROP 1826 includes one or more lighting / hidden surface removal (HSR) units to perform these operations. In at least one embodiment, ROP 1826 also includes one or more texture engines to perform texture mapping operations for pixel and / or fragment data. In at least one embodiment, texture mapping works in conjunction with data that is received from one or more parallel processor(s) 1800 to perform texture mapping operations. FIG. 18A In at least one embodiment, ROP 1826 is included in each processing cluster 1814 (e.g., within cluster 1814A-1814N) instead of in partition unit 1820. In at least one embodiment, read and write requests for pixel data are transmitted over memory crossbar 1816 instead of pixel fragment data. In at least one embodiment, processed graphics data can be displayed on one or more display devices 1710, routed to a FIG. 17 processor 1702 for further processing, or routed to one of processing entities within parallel processor 1800 for further processing. FIG. 18A

[0295] FIG. 18C is a block diagram of a processing cluster 1814 within a parallel processing unit according to at least one embodiment. In at least one embodiment, processing cluster is a FIG. 18A ​​one of the processing clusters 1814A-1814N. In at least one embodiment, processing cluster 1814 can be configured to execute many threads in parallel, where a “thread” refers to an instance of a particular program executed by a particular group of one or more processors. In at least one embodiment, Single-Instruction, Multiple-Data (SIMD) instruction issue techniques are used to support parallel execution of a large number of threads with no or negligible program overhead. In at least one embodiment, Single-Instruction, Multiple Thread (SIMT) techniques are used to support parallel execution of a large number of threads seeking common functionality, in at least one embodiment, a common instruction unit is configured to issue instructions to a group of processing engines within each processing cluster.

[0296] In at least one embodiment, operation of processing cluster 1814 can be controlled via a pipeline manager 1832 that allocates processing tasks to SIMT parallel processors. In at least one embodiment, pipeline manager 1832 receives instructions from scheduler 1810 and manages execution of those instructions via graphics multiprocessor 1834 and / or texture unit 1836. In at least one embodiment, graphics multiprocessor 1834 is an exemplary instance of a SIMT parallel processor. However, in at least one embodiment, various types of SIMT parallel processors of differing architectures can be included within processing cluster 1814. In at least one embodiment, one or more instances of graphics multiprocessor 1834 can be included within processing cluster 1814. In at least one embodiment, graphics multiprocessor 1834 can process data and a data crossbar 1840 can be used to facilitate communication between graphics multiprocessor 1834 and one or more of a number of possible destinations. FIG. 18A

[0297] In at least one embodiment, each graphics multiprocessor 1834 within processing cluster 1814 can include an identical set of functional execution logic (e.g., arithmetic logic units, load-store units, etc.). In at least one embodiment, functional execution logic can be configured in a pipelined manner in which new instructions can be issued before previous instructions are complete. In at least one embodiment, functional execution logic supports a variety of operations including integer and floating point arithmetic, comparison operations, Boolean operations, bit-shifting operations, and compute operations. In at least one embodiment, same functional-unit hardware can be leveraged to perform different operations using different code paths within those units and any combinations of operations

[0298] ​In at least one embodiment, instructions delivered to processing cluster 1814 constitute a thread. In at least one embodiment, a set of threads executing across a set of parallel processing engines constitutes a warp. In at least one embodiment, a thread group comprises a plurality of threads to be executed on a plurality of

[0299] In at least one embodiment, graphics multiprocessor 1834 includes internal cache memory which speed up access to frequently-accessed data. In at least one embodiment, graphics multiprocessor 1834 can discard internal cache and use cache memory within processing cluster 1814 (e.g., LI cache 1848). In at least one embodiment, each graphics multiprocessor 1834 can also have access to L2 cache within a partition unit (e.g., partition unit 1820A-1820N) that is shared among all processing clusters 1814 and can be used to transfer data between threads. In at least one embodiment, graphics multiprocessor 1834 can also have access to off-chip global memory, which can include one or more of local parallel processor memory and / or system memory. In at least one embodiment, any memory external to parallel processor 1802 can be used as global memory. In at least one embodiment, processing cluster 1814 includes multiple instances of graphics multiprocessor 1834 which share common instructions and data, which can be stored in LI cache 1848. FIG. 18A

[0300] In at least one embodiment, each processing cluster 1814 can include a memory management unit (MMU) 1845 configured to translate virtual addresses into physical addresses, in at least one embodiment, one or more instances of MMU 1845 can reside within graphics multiprocessor 1834. In at least one embodiment, MMU 1845 includes address translation lookaside buffers (TLBs) for accessing translated addresses in memory. In at least one embodiment, TLBs enable translation of a long address to a short address form for accessing memory. FIG. 18A ​In at least one embodiment, MMU 1845 includes a set of page table entries (PTEs) used to map virtual addresses into physical addresses for task computation and / or graphics operations. In at least one embodiment, MMU 1845 can include address translation lookaside buffer (TLB) or cache to improve translation from virtual addresses to physical addresses by storing previous address translations in buffer / memory to allow for speedier translations. In at least one embodiment, physical addresses are processed to allocate surface data access locality to enable efficient request interleaving among partition units.

[0301] In at least one embodiment, processing cluster 1814 can be configured such that each graphics multiprocessor 1834 is coupled to a texture unit 1836 for performing texture mapping operations in conjunction with various graphics applications. In at least one embodiment, texture unit 1836 determines if texture data is to be accessed from internal texture-Ll cache or from L2 cache, either alone or in combination with the internal texture-Ll cache. In at least one embodiment, texture data can also be accessed from a system memory, graphics processing cluster 1814, or a shared memory, either alone or in combination with the internal texture-Ll cache and / or L2 cache. In at least one embodiment, texture unit 1836 can also be configured to perform address translations from texture coordinates to texture data in memory. FIG. 6A

[0302] Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. FIG. 6B FIG. 18A Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 can be used in graphics processing cluster 1814 for inferencing or predicting operations based, at least in part, on weight parameters calculated using neural network training operations, neural network functions and / or architectures, or neural network use cases described herein.

[0303] ​​In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used in conjunction with FIG. 18D -C are used in conjunction with features of and can be configured to receive sensor inputs from a plurality of sensors and can be trained to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor inputs to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor inputs can be correlated with different classes of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such a different class of sensor inputs can indicate a cooling demand, or a change therein.

[0304] FIG. 6A A graphics processing unit 1834 according to at least one embodiment is shown. In at least one embodiment, graphics processing unit 1834 is coupled with a pipeline manager 1832 of processing cluster 1814. In at least one embodiment, graphics processing unit 1834 has an execution pipeline that includes, without limitation, an instruction cache 1852, an instruction unit 1854, an address mapping unit 1856, a register file 1858, one or more general-purpose graphics processing unit (GPGPU) cores 1862, and one or more load / store units 1866 that can perform load / store operations to load / store instructions corresponding to execution operations. In at least one embodiment, GPGPU cores 1862 and load / store units 1866 are coupled with a memory and cache interconnect 1868 to cache memory 1872 and shared memory 1870.

[0305] In at least one embodiment, instruction cache 1852 receives a stream of instructions to execute from pipeline manager 1832. In at least one embodiment, instructions are cached in instruction cache 1852 and dispatched for execution by instruction unit 1854. In at least one embodiment, instruction unit 1854 can dispatch instructions as a thread group (e.g., a thread warp, wavefront, wave) where each thread in the thread group is assigned to a different execution unit within GPGPU cores 1862. In at least one embodiment, instructions can access any of local, shared, or global address spaces by specifying an address in a unified address space. In at least one embodiment, address mapping unit 1856 can be used to translate an address in the unified address space into a different address that can be accessed by load / store units 1866.

[0306] In at least one embodiment, register file 1858 provides a set of registers for the functional units of graphics processor 1834. In at least one embodiment, register file 1858 provides temporary storage for operands of the data

[0307] In at least one embodiment, GPGPU cores 1862 can each include floating point

[0308] In at least one embodiment, GPGPU cores 1862 include SIMD logic capable of

[0309] In at least one embodiment, memory and cache interconnect 1868 is an interconnect network that connects each functional unit of graphics multiprocessor 1834 to register file 1858 and shared memory 1870. In at least one embodiment, memory and cache interconnect 1868 is a crossbar interconnect that allows load / store units 1866 to implement load and store operations between shared memory 1870 and register file 1858. In at least one embodiment, register file 1858 can operate at same frequency as GPGPU cores 1862, such that latency for data transfers between GPGPU cores 1862 and register file 1858 is very low. In at least one embodiment, shared memory 1870 can be used to enable communication between threads executing on functional units within graphics multiprocessor 1834. In at least one embodiment, cache memory 1872 can be used as, for example, a data cache to cache texture data communicated between texture unit 1836 and functional units. In at least one embodiment, shared memory 1870 can also be used as a program managed cache. In at least one embodiment, in addition to auto-cached data stored in cache memory 1872, threads executing on GPGPU cores 1862 can also store data in shared memory in a programmed manner.

[0310] In at least one embodiment, parallel processor or GPGPU as described herein is communicatively coupled to host / processor cores to accelerate graphics operations, machine learning operations, pattern analysis operations, and various general purpose GPU (GPGPU) functions. In at least one embodiment, GPU can be communicatively coupled to host processor / cores by a bus or other interconnect (e.g., a high speed

[0311] Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and 6M. In at least one embodiment, inference and / or training logic 615 is used in conjunction with components of system 600, for example, to perform inferencing operations, training operations, and / or similar operations. FIG. 6B and / or FIG. 18DDetails regarding the inference and / or training logic 615 are provided. In at least one embodiment, the inference and / or training logic 615 can be used in graphics multi-processor 1834 for performing inferencing or predicting operations associated with neural networks, based, at least in part, on weight parameters calculated using neural network training operations, neural network functions and / or architectures, or neural network use cases described herein.

[0312] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used in conjunction with features of the NVIDIA DRIVE AGX PARRY™, and can be configured to receive sensor inputs from a plurality of sensors, and can be trained to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor inputs to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can infer a change in coolant demand. In at least one embodiment, sensor inputs can be correlated to different classes of coolant demand for each different sensor input. In at least one embodiment, a new sensor input classified in such different classes of sensor input can be indicative of coolant demand, or a change thereof. FIG. 19

[0313] FIG. 6A ​A multi-GPU computing system 1900 is shown in accordance with at least one embodiment. In at least one embodiment, multi-GPU computing system 1900 can include a processor 1902 coupled to a plurality of general purpose graphics processing units (GPGPUs) 1906A-D via a host interface switch 1904. In at least one embodiment, host interface switch 1904 is a PCI Express switch device that couples processor 1902 to a PCI Express bus over which processor 1902 can communicate with GPGPUs 1906A-D. In at least one embodiment, GPGPUs 1906A-D can be interconnected via a set of high-speed P2P (point-to-point) GPU-to-GPU links 1916. In at least one embodiment, GPU-to-GPU links 1916 connect to each of GPGPUs 1906A-D via a dedicated GPU link. In at least one embodiment, P2P GPU links 1916 enable direct communication between each GPGPU 1906A-D without having to communicate through host interface bus 1904 to which processor 1902 is connected. In at least one embodiment, where GPU-to-GPU traffic is directed to P2P GPU links 1916, host interface bus 1904 remains available for system memory access or communication with other instances of multi-GPU computing system 1900, e.g., via one or more network devices. While in at least one embodiment GPGPUs 1906A-D are connected to processor 1902 via host interface switch 1904, in at least one embodiment processor 1902 includes direct support for P2P GPU links 1916 and can be directly connected to GPGPUs 1906A-D.

[0314] Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. FIG. 6B and / or FIG. 19 Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 can be used in multi-GPU computing system 1900 for inferencing or predicting operations based, at least in part, on weight parameters calculated using neural network training operations, neural network functions and / or architectures, or neural network use cases described herein.

[0315] In at least one embodiment, multi-GPU computing system 1900 includes one or more graphics cores 1600.

[0316] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used in conjunction with FIG. 20features are used in combination and can be configured to receive sensor inputs from multiple sensors and can be trained to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor inputs to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor inputs can be correlated with different classes of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such a different class of sensor inputs can be indicative of a cooling demand, or a change thereof.

[0317] FIG. 6A FIG. 21 is a block diagram of a graphics processor 2000 that may

[0318] In at least one embodiment, graphics processor 2000 receives batches of commands via ring interconnect 2002. In at least one embodiment, incoming commands are interpreted by a command streamer 2003 in pipeline front-end 2004. In at least one embodiment, graphics processor 2000 includes scalable execution logic to perform 3D geometry processing and media processing via the graphics cores 2080A-2080N. In at least one embodiment, for 3D geometry processing commands, command streamer 2003 supplies commands to geometry pipeline 2036. In at least one embodiment, for at least some media processing commands, command streamer 2003 supplies

[0319] In at least one embodiment, graphics processor 2000 includes a scalable thread execution resource featuring graphics cores 2080A-2080N (which can be modular and sometimes referred to as core slices), each including a number of sub-cores 2050A-2050N, 2060A-2060N (sometimes referred to as core sub-slices). In at least one embodiment, graphics processor 2000 can have any number of graphics cores 2080A. In at least one embodiment, graphics processor 2000 includes graphics core 2080A having at least a first sub-core 2050A and a second sub-core 2060A. In at least one embodiment, graphics processor 2000 is a low power processor with a single sub-core (e.g., 2050A). In at least one embodiment, graphics processor 2000 includes multiple graphics cores 2080A-2080N each including a set of first sub-cores 2050A-2050N and a set of second sub-cores 2060A-2060N. In at least one embodiment, each sub-core in first sub-cores 2050A-2050N includes at least a first set of execution units 2052A-2052N and media / texture samplers 2054A-2054N. In at least one embodiment, each sub-core in second sub-cores 2060A-2060N includes at least a second set of execution units 2062A-2062N and samplers 2064A-2064N. In at least one embodiment, each sub-core 2050A-2050N, 2060A-2060N shares a set of shared resources 2070A-2070N. In at least one embodiment, shared resources include shared cache memory and pixel operation logic. In at least one embodiment, graphics processor 2000 includes a

[0320] Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. FIG. 6B and / or FIG. 20 Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 can be used in graphics processor 2000 for inferencing or predicting operations, based at least in part on weight parameters calculated using neural network training operations, neural network functions and / or architectures, or neural network use cases described herein.

[0321] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used in conjunction with FIG. 21The features of the system 600 can be used in combination and can be configured to receive sensor inputs from multiple sensors and can be trained to infer coolant demand. In at least one embodiment, the inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor inputs to infer coolant demand. In at least one embodiment, the inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor inputs can be correlated to different classes of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such a different class of sensor inputs can be indicative of a cooling demand, or a change thereof.

[0322] FIG. 6A FIG. 21 is a block diagram illustrating micro-architecture of a processor 2100 that can include logic to execute instructions, according to at least one embodiment. In at least one embodiment, processor 2100 can execute instructions including x86 instructions, ARM instructions, specialized instructions for application specific integrated circuits (ASICs), and the like. In at least one embodiment, processor 2100 can include registers to store packed data, such as 64-bit wide MMX TM registers implemented with MMX technology by Intel Corporation of Santa Clara, California. In at least one embodiment, MMX registers available in both integer and floating point number form can operate with packed data elements that accompany single instruction multiple data (“SIMD”) and streaming SIMD extensions (“SSE”) instructions. In at least one embodiment, 128-bit wide XMM registers related to SSE2, SSE3, SSE4, AVX, or beyond (generically referred to as “SSEx”) technology can hold such packed data operands. In at least one embodiment, processor 2100 can execute instructions to accelerate machine learning or deep learning algorithms, training, or inference.

[0323] In at least one embodiment, processor 2100 includes an in-order front-end (“front-end”) 2101 to fetch instructions to be executed and prepare instructions to be used later in processor pipeline. In at least one embodiment, front-end 2101 can include several units. In at least one embodiment, instruction prefetcher 2126 fetches instructions from memory and feeds them to instruction decoder 2128 which in turn decodes or interprets them. For example, in at least one embodiment, instruction decoder 2128 decodes a received instruction into one or more operations called “micro-operations” or “microinstructions” (also called “micro ops” or “uops” or “μ-ops”) that are executable by a machine. In at least one embodiment, instruction decoder 2128 parses the instruction into an operation code and corresponding data and control fields that are used by micro-architecture to perform the instruction according to at least one embodiment. In at least one embodiment, a trace cache 2130 can assemble decoded micro-ops into program ordered sequences or traces in a micro-op queue 2134 for execution. In at least one embodiment, when trace cache 2130 encounters a complex instruction, microcode ROM 2132 provides the micro-ops needed to complete the operation.

[0324] In at least one embodiment, some instructions are converted into a single micro- operation, while others are broken down into multiple micro-operations for complete execution. In at least one embodiment, if more than four micro-operations are needed to complete an instruction, then instruction decoder 2128 can access microcode ROM 2132 to perform the instruction. In at least one embodiment, instructions can be decoded into a small number of micro-operations for processing at instruction decoder 2128. In at least one embodiment, if multiple micro-operations are needed to complete the operation, then the instruction can be stored in microcode ROM 2132. In at least one embodiment, trace cache 2130 references an entry point programmable logic array (“PLA”) to determine the correct microinstruction pointer for reading a microcode sequence from microcode ROM 2132 to complete one or more instructions according to at least one embodiment. In at least one embodiment, after microcode ROM 2132 sequences the micro-operations for an instruction, front-end 2101 of the machine can resume fetching micro-operations from trace cache 2130.

[0325] In at least one embodiment, out-of-order execution engine (“out-of-order engine”) 2103 can prepare instructions for execution. In at least one embodiment, out-of-order execution logic has a number of buffers to smooth and reorder instruction flow to optimize performance as instruction flow progresses down a pipeline and is scheduled for execution. In at least one embodiment, out-of-order execution engine 2103 includes, without limitation, an allocator / register renamer 2140, a memory micro-op queue 2142, an integer / floating point micro-op queue 2144, a memory scheduler 2146, a fast scheduler 2102, a slow / general floating point scheduler (“slow / general FP scheduler”) 2104, and a simple floating point scheduler (“simple FP scheduler”) 2106. In at least one embodiment, fast scheduler 2102, slow / general floating point scheduler 2104, and simple floating point scheduler 2106 are also referred to herein collectively as “micro-op schedulers 2102, 2104, 2106”. In at least one embodiment, allocator / register renamer 2140 allocates machine buffers and resources needed for each micro-op for execution. In at least one embodiment, allocator / register renamer 2140 renames logical registers to entries in a register file. In at least one embodiment, allocator / register renamer 2140 also allocates an entry for each micro-op in one of two micro-op queues, a memory micro-op queue 2142 for memory operations and an integer / floating point micro-op queue 2144 for non-memory operations, in front of memory scheduler 2146 and micro-op schedulers 2102, 2104, 2106. In at least one embodiment, micro-op schedulers 2102, 2104, 2106 determine when micro-ops are ready to execute based on readiness of their dependent input register operand sources and availability of execution resources needed for micro-ops to complete their operations. In at least one embodiment, fast scheduler 2102 can schedule on every half of a main clock cycle, while slow / general floating point scheduler 2104 and simple floating point scheduler 2106 can schedule once per main processor clock cycle. In at least one embodiment, micro-op schedulers 2102, 2104, 2106 arbitrate for a dispatch port to schedule micro-ops for execution.

[0326] In at least one embodiment, execution block 2111 includes, without limitation, an integer register file / bypass network 2108, a floating point register file / bypass network (“FP register file / bypass network”) 2110, address generation units (“AGUs”) 2112 and 2114, fast arithmetic logic units (“ALUs”) 2116 and 2118, slow ALUs 2120, floating point ALUs (“FPs”) 2122, and floating point move units (“FPMs”) 2124. In at least one embodiment, integer register file / bypass network 2108 and floating point register file / bypass network 2110 are also referred to herein as “register files 2108, 2110.” In at least one embodiment, AGUs 2112 and 2114, fast ALUs 2116 and 2118, slow ALUs 2120, FPs 2122, and FPMs 2124 are also referred to herein as “execution units 2112, 2114, 2116, 2118, 2120, 2122, and 2124.” In at least one embodiment, execution block 2111 can include any number and type of register files, bypass networks, address generation units, and execution units in any combination.

[0327] In at least one embodiment, register networks 2108, 2110 can be arranged between microoperation schedulers 2102, 2104, 2106 and execution units 2112, 2114, 2116, 2118, 2120, 2122, and 2124. In at least one embodiment, integer register file / bypass network 2108 performs integer operations. In at least one embodiment, floating point register file / bypass network 2110 performs floating point operations. In at least one embodiment, each of register networks 2108, 2110 can include, without limitation, a bypass network that can bypass results of an operation that have not yet been written into a register file to a new dependent microoperation or forward them. In at least one embodiment, register networks 2108, 2110 can communicate data to each other. In at least one embodiment, integer register file / bypass network 2108 can include, without limitation, two separate register files, one for low-order 32 bits and one for high-order 32 bits. In at least one embodiment, floating point register file / bypass network 2110 can include, without limitation, 128-bit wide entries, as floating point instructions typically have 64- to 128-bit operands.

[0328] In at least one embodiment, execution units 2112, 2114, 2116, 2118, 2120, 2122, 2124 can execute instructions. In at least one embodiment, register files 2108, 2110 store integer and floating point data operand values that microinstructions need to operate on. In at least one embodiment, processor 2100 can include, without limitation, any number of execution units 2112, 2114, 2116, 2118, 2120, 2122, 2124 and combinations thereof. In at least one embodiment, floating point ALU 2122 and floating point move unit 2124 can perform floating point, MMX, SIMD, AVX and SSE, or other operations, including specialized machine learning instructions. In at least one embodiment, floating point ALU 2122 can include, without limitation, a 64 bit by 64 bit floating point divider to execute divide, square root, and remainder micro-ops. In at least one embodiment, instructions for working on floating point values can be handled with floating point hardware. In at least one embodiment, ALU operations can be passed to fast ALUs 2116, 2118. In at least one embodiment, fast ALUs 2116, 2118 can execute fast operations in a single clock cycle. In at least one embodiment, most complex integer operations enter slow ALU 2120 because slow ALU 2120 can include, without limitation, integer execution hardware for long latency type of operations such as a multiplier, a shift, flag logic, and branch processing. In at least one embodiment, memory load / store operations can be executed by AGUs 2112, 2114. In at least one embodiment, fast ALUs 2116, fast ALUs 2118, and slow ALU 2120 can execute integer operations on 64 bit data operands. In at least one embodiment, fast ALUs 2116, fast ALUs 2118, and slow ALU 2120 can be implemented to support a range of operand data bit sizes including sixteen, thirty-two, 128, 256, etc. In at least one embodiment, floating point ALU 2122 and floating point move unit 2124 can be implemented to support a range of operands with bits of various widths including 128 bit wide packed data operands in conjunction with SIMD and multimedia instructions.

[0329] In at least one embodiment, micro-op schedulers 2102, 2104, 2106 dispatch dependent operations before parent loads have completed execution. In at least one embodiment, because micro-ops can be speculatively scheduled and executed in processor 2100, processor 2100 can also include logic to handle memory misses. In at least one embodiment, if a data load in a data cache misses, there can be dependent operations running in the pipeline that cause the scheduler to temporarily have incorrect data. In at least one embodiment, a replay mechanism tracks and re-executes instructions that used incorrect data. In at least one embodiment, dependent operations can need to be replayed and independent operations can be allowed to complete. In at least one embodiment, a scheduler and replay mechanism of at least one embodiment of a processor can also be designed to capture instruction sequences for text string compare operations.

[0330] In at least one embodiment, a “register” can refer to an on-board processor storage location that can be used as part of an instruction that identifies an operand. In at least one embodiment, a register can be one that can be used from outside of a processor (from a programmer’s perspective). In at least one embodiment, a register can not be limited to a particular type of circuit. Rather, in at least one embodiment, a register can store data, provide data, and perform functions described herein. In at least one embodiment, registers described herein can be implemented by circuitry within a processor using any number of different techniques, such as dedicated physical registers, dynamically allocated physical registers using register renaming, a combination of dedicated and dynamically allocated physical registers, etc. In at least one embodiment, an integer register stores 32-bit integer data. A register file of at least one embodiment also contains eight multimedia SIMD registers for packed data.

[0331] In at least one embodiment, processor 2100 or each core of processor 2100 includes one or more prefetchers, one or more fetchers, one or more pre-decoders, one or more decoders to decode data (e.g., instructions), one or more instruction queues to process instructions (e.g., corresponding to operations or API calls), one or more micro-ops (uOP) caches to store uOPs, one or more uOP queues, an in-order execution engine, one or more load buffers, one or more store buffers, one or more reorder buffers, one or more fill buffers, an out-of-order execution engine, one or more ports, one or more shift and / or shifter units, one or more fused multiply-add (FMA) units, one or more load and store units (“LSUs”) to perform loads corresponding to load / store data (e.g., instructions) to perform operations (e.g., execute APIs, API calls), one or more matrix multiply-add (MMA) units, and / or one or more shuffle units to perform any functionality described herein with respect to processor 2100. In at least one embodiment, processor 2100 can access, use, execute, or perform instructions corresponding to a calling API.

[0332] In at least one embodiment, processor 2100 includes one or more Ultra Path Interconnects (UPIs), e.g., which are point-to-point processor interconnects; one or more PCle; one or more accelerators for accelerated computing or operations; and / or one or more memory controllers. In at least one embodiment, processor 2100 includes a shared last level cache (LLC) coupled to one or more memory controllers, which can enable shared memory access across processor cores.

[0333] In at least one embodiment, processor 2100 or cores of processor 2100 have a mesh architecture in which processor cores, on-chip caches, memory controllers, and I / O controllers are organized into rows and columns with wires and switches connecting them at each intersection to allow turns. In at least one embodiment, processor 2100 has one or more higher memory bandwidths (HMBs, e.g., HMBe) to store data or cache data, such as in double data rate 5 synchronous dynamic random access memory (DDR5 SDRAM). In at least one embodiment, one or more components of processor 2100 are interconnected using a compute express link (CXL) interconnect. In at least one embodiment, a memory controller uses a “least recently used” (LRU) approach to determine what to store in a cache. In at least one embodiment, processor 2100 includes one or more PCle (e.g., PCle 5.0).

[0334] Inference and / or training logic 615 is used to perform inference and / or training operations associated with one or more embodiments. This document combines... FIG. 6B and / or FIG. 21 Details regarding the inference and / or training logic 615 are provided. In at least one embodiment, some or all of the inference and / or training logic 615 may be incorporated into execution block 2111 and other memories or registers shown or not shown. For example, in at least one embodiment, the training and / or inference techniques described herein may use one or more ALUs shown in execution block 2111. Furthermore, weight parameters may be stored in on-chip or off-chip memory and / or registers (shown or not shown) that configure the ALUs of execution block 2111 to execute one or more machine learning algorithms, neural network architectures, use cases, or training techniques described herein.

[0335] In at least one embodiment, one or more neural networks of the inference and / or training logic 615 can be connected with... FIG. 22 The features are used together and can be configured to receive sensor inputs from multiple sensors, and can be trained to infer coolant demand. In at least one embodiment, the inference and / or training logic 615 is capable of inferring coolant demand using information from historical cooling demand and historical sensor inputs. In at least one embodiment, the inference and / or training logic 615 can infer changes in cooling demand. In at least one embodiment, sensor inputs can be associated with different categories of cooling demand for each different sensor input. In at least one embodiment, new sensor inputs categorized within these different categories of sensor inputs can indicate cooling demand, or changes thereof.

[0336] FIG. 6AA deep learning application processor 2200 is shown, in accordance with at least one embodiment. In at least one embodiment, deep learning application processor 2200 uses instructions that, if executed by deep learning application processor 2200, cause deep learning application processor 2200 to perform some or all of the processes and techniques described throughout this disclosure. In at least one embodiment, deep learning application processor 2200 is an application specific integrated circuit (ASIC). In at least one embodiment, as a result of executing one or more instructions or both, application processor 2200 performs matrix multiplication operations or is “hardwired” into hardware. In at least one embodiment, deep learning application processor 2200 includes, without limitation, processing clusters 2210(1)-2210(12), inter-chip links (“ICLs”) 2220(1)-2220(12), inter-chip controllers (“ICCs”) 2230(1)-2230(2), second generation high bandwidth memory (“HBM2”) 2240(1)-2240(4), memory controllers (“Mem Ctrlrs”) 2242(1)-2242(4), high bandwidth memory physical layers (“HBM PHYs”) 2244(1)-2244(4), management controller central processing units (“management controller CPUs”) 2250, serial peripheral interfaces, internal integrated circuits, and general purpose input / output blocks (“SPI, I2C, GPIO”) 2260, peripheral component interconnect express controllers and direct memory access blocks (“PCIe controllers and DMA”) 2270, and sixteen lane peripheral component interconnect express ports (“PCI Express x 16”) 2280. 2 C、GPIO”) 2260, peripheral component interconnect express controllers and direct memory access blocks (“PCIe controllers and DMA”) 2270, and sixteen lane peripheral component interconnect express ports (“PCI Express x 16”) 2280.

[0337] In at least one embodiment, processing clusters 2210 can perform deep learning operations, including inferencing or prediction operations based on weight parameters calculated by one or more training techniques, including those described herein. In at least one embodiment, each processing cluster 2210 can include, without limitation, any number and type of processors. In at least one embodiment, deep learning application processor 2200 can include any number and type of processing clusters 2200. In at least one embodiment, inter-chip links 2220 are bidirectional. In at least one embodiment, inter-chip links 2220 and inter-chip controllers 2230 enable multiple deep learning application processors 2200 to exchange information, including activation information resulting from execution of one or more machine learning algorithms embodied in one or more neural networks. In at least one embodiment, deep learning application processor 2200 can include any number (including zero) and type of ICLs 2220 and ICCs 2230.

[0338] In at least one embodiment, the HBM2 2240 provides a total of 32GB of memory. In at least one embodiment, the HBM2 2240(i) is associated with both the memory controller 2242(i) and the HBM PHY 2244(i), where “i” is any integer. In at least one embodiment, any number of HBM2 2240s can provide any type and total amount of high-bandwidth memory and can be associated with any number (including zero) and type of memory controller 2242 and HBM PHY 2244. In at least one embodiment, any number and type of blocks implementing any number and type of communication standards can replace SPI, I... 2 C. GPIO 2260, PCIe controller and DMA 2270 and / or PCIe 2280.

[0339] Inference and / or training logic 615 is used to perform inference and / or training operations associated with one or more embodiments. This document combines... FIG. 6B and / or FIG. 22 Details regarding the inference and / or training logic 615 are provided. In at least one embodiment, the deep learning application processor is used to train a machine learning model (such as a neural network) to predict or infer information provided to the deep learning application processor 2200. In at least one embodiment, the deep learning application processor 2200 is used to infer or predict information based on a trained machine learning model (e.g., a neural network) that has been trained by another processor or system or by the deep learning application processor 2200. In at least one embodiment, the processor 2200 may be used to perform one or more neural network use cases described herein.

[0340] In at least one embodiment, one or more neural networks of the inference and / or training logic 615 can be connected with... FIG. 23 The features are used in combination and can be configured to receive sensor inputs from multiple sensors, and can be trained to infer coolant demand. In at least one embodiment, the inference and / or training logic 615 is capable of inferring coolant demand using information from historical cooling demand and historical sensor inputs. In at least one embodiment, the inference and / or training logic 615 can infer changes in cooling demand. In at least one embodiment, sensor inputs can be associated with different categories of cooling demand for each different sensor input. In at least one embodiment, new sensor inputs categorized within these different categories of sensor inputs can indicate cooling demand, or changes thereof.

[0341] FIG. 23is a block diagram of a neuromorphic processor 2300, in accordance with at least one embodiment. In at least one embodiment, neuromorphic processor 2300 can receive one or more inputs from a source external to neuromorphic processor 2300. In at least one embodiment, these inputs can be communicated to one or more neurons 2302 within neuromorphic processor 2300. In at least one embodiment, neurons 2302 and components thereof can be implemented using circuitry or logic including one or more arithmetic logic units (ALUs). In at least one embodiment, neuromorphic processor 2300 can include, without limitation, thousands or millions of instances of neurons 2302, but any suitable number of neurons 2302 can be used. In at least one embodiment, each instance of neurons 2302 can include neuron input 2304 and neuron output 2306. In at least one embodiment, neurons 2302 can generate outputs that can be communicated to inputs of other instances of neurons 2302. In at least one embodiment, neuron input 2304 and neuron output 2306 can be interconnected via synapses 2308.

[0342] In at least one embodiment, neurons 2302 and synapses 2308 can be interconnected such that neuromorphic processor 2300 operates to process or analyze information received by neuromorphic processor 2300. In at least one embodiment, a neuron 2302 can send an output pulse (or “fire” or “spike”) when input received through neuron input 2304 exceeds a threshold value. In at least one embodiment, neuron 2302 can sum or integrate signals received at neuron input 2304. For example, in at least one embodiment, neuron 2302 can be implemented as a leaky integrate-and-fire neuron, where neuron 2302 can produce an output (or “fire”) using a transfer function such as a sigmoid or threshold function if a sum (referred to as “membrane potential”) exceeds a threshold value. In at least one embodiment, a leaky integrate-and-fire neuron can sum signals received at neuron input 2304 into a membrane potential, and can also apply a decay factor (or leak) to reduce the membrane potential. In at least one embodiment, a leaky integrate-and-fire neuron can fire if multiple input signals are received at neuron input 2304 fast enough to exceed a threshold value (i.e., before the membrane potential decays too low to fire). In at least one embodiment, neuron 2302 can be implemented using circuitry or logic that receives input, integrates input into a membrane potential, and decays the membrane potential. In at least one embodiment, input can be averaged, or any other suitable transfer function can be used. Furthermore, in at least one embodiment, neuron 2302 can include, without limitation, a comparator circuit or logic that produces an output spike at neuron output 2306 when a result of applying a transfer function to neuron input 2304 exceeds a threshold value. In at least one embodiment, once neuron 2302 fires, it can ignore previously received input information by, for example, resetting the membrane potential to 0 or another suitable default value. In at least one embodiment, once the membrane potential is reset to 0, neuron 2302 can resume normal operation after a suitable period of time (or refractory period).

[0343] In at least one embodiment, neurons 2302 can be interconnected by synapses 2308. In at least one embodiment, synapses 2308 can operate to send signals from an output of a first neuron 2302 to an input of a second neuron 2302. In at least one embodiment, a neuron 2302 can communicate information over more than one instance of a synapse 2308. In at least one embodiment, one or more instances of a neuron output 2306 can be connected via an instance of a synapse 2308 to an instance of a neuron input 2304 in the same neuron 2302. In at least one embodiment, an instance of a neuron 2302 that produces an output to be communicated over an instance of a synapse 2308 can be referred to as a “presynaptic neuron” with respect to that instance of a synapse 2308. In at least one embodiment, an instance of a neuron 2302 that receives an input communicated through an instance of a synapse 2308 can be referred to as a “postsynaptic neuron” with respect to that instance of a synapse 2308. In at least one embodiment, with respect to various instances of synapses 2308, because an instance of a neuron 2302 can receive inputs from one or more instances of synapses 2308 and can also communicate outputs through one or more instances of synapses 2308, a single instance of a neuron 2302 can be both a “presynaptic neuron” and a “postsynaptic neuron”.

[0344] In at least one embodiment, neurons 2302 can be organized into one or more layers. In at least one embodiment, each instance of a neuron 2302 can have a neuron output 2306 that can fan out to one or more neuron inputs 2304 through one or more synapses 2308. In at least one embodiment, neuron outputs 2306 of neurons 2302 in a first layer 2310 can be connected to neuron inputs 2304 of neurons 2302 in a second layer 2312. In at least one embodiment, layer 2310 can be referred to as a “feedforward layer”. In at least one embodiment, each instance of a neuron 2302 in an instance of a first layer 2310 can fan out to every instance of a neuron 2302 in a second layer 2312. In at least one embodiment, first layer 2310 can be referred to as a “fully connected feedforward layer”. In at least one embodiment, each instance of a neuron 2302 in an instance of a second layer 2312 can fan out to fewer than all instances of a neuron 2302 in a third layer 2314. In at least one embodiment, second layer 2312 can be referred to as a “sparsely connected feedforward layer”. In at least one embodiment, neurons 2302 in second layer 2312 can fan out to neurons 2302 in multiple other layers, including to neurons 2302 that are also in second layer 2312. In at least one embodiment, second layer 2312 can be referred to as a “recurrent layer”. In at least one embodiment, neuromorphic processor 2300 can include any suitable combination of recurrent and feedforward layers, including but not limited to sparsely connected and fully connected feedforward layers.

[0345] In at least one embodiment, neuromorphic processor 2300 can include, without limitation, a reconfigurable interconnect architecture or a dedicated hardwired interconnect for connecting synapses 2308 to neurons 2302. In at least one embodiment, neuromorphic processor 2300 can include, without limitation, circuitry or logic that allows synapses to be allocated to different neurons 2302 as needed based on a neural network topology and neuron fan-in / fan-out. For example, in at least one embodiment, synapses 2308 can be connected to neurons 2302 using an interconnect structure such as a network-on-chip or with dedicated connections. In at least one embodiment, synapse interconnects and components thereof can be implemented using circuitry or logic.

[0346] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used for implementing neural processing methods described herein. FIG. 24The features of the system 600 can be used in combination and can be configured to receive sensor inputs from multiple sensors and can be trained to infer coolant demand. In at least one embodiment, the inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor inputs to infer coolant demand. In at least one embodiment, the inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor inputs can be correlated to different classes of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such a different class of sensor inputs can be indicative of a cooling demand, or a change thereof.

[0347] FIG. 6A The system 2400 is a processing system, in accordance with at least one embodiment. In at least one embodiment, the system 2400 includes one or more processor(s) 2402 and one or more graphics processor(s) 2408, and can be a single processor desktop system, a multiprocessor work station system, or a server system with large numbers of processors 2402 or processor cores 2407. In at least one embodiment, the system 2400 is a processing platform contained within a system-on-a-chip (SoC) integrated circuit for use in mobile, handheld, or embedded devices. In at least one embodiment, the one or more graphics processor(s) 2408 include one or more graphics core(s) 1600.

[0348] In at least one embodiment, the system 2400 can include or be incorporated within a server-based gaming platform, a game console including a gaming and media console, a mobile gaming console, a handheld game console, or an online game console. In at least one embodiment, system 2400 is a mobile phone, a smart phone, a tablet device, or a mobile internet device. In at least one embodiment, processing system 2400 can also include or be coupled with a wearable device such as a smart watch wearable device, smart glasses device, augmented reality device, or virtual reality device. In at least one embodiment, processing system 2400 is a television or set-top box device having one or more processors 2402 and graphical interfaces generated by one or more graphics processors 2408.

[0349] In at least one embodiment, each of processor(s) 2402 includes one or more processor cores 2407 for processing instructions that, when executed, perform operations for system and user software. In at least one embodiment, each of processor core(s) 2407 is configured to process a specific instruction sequence 2409. In at least one embodiment, instruction sequence 2409 can facilitate complex instruction set computing (CISC), reduced instruction set computing (RISC), or computing via a very long instruction word (VLIW). In at least one embodiment, processor cores 2407 can each process different instruction sequences 2409 that can include instructions to facilitate emulation of other instruction sequences. In at least one embodiment, processor cores 2407 can also include other processing devices, such as digital signal processors (DSPs).

[0350] In at least one embodiment, processor(s) 2402 include cache memory 2404. In at least one embodiment, processor(s) 2402 can have a single internal cache or multiple levels of internal caches. In at least one embodiment, cache memory is shared among multiple components of processor(s) 2402. In at least one embodiment, processor(s) 2402 also use an external cache (e.g., a three-level (L3) cache, or last level cache (LLC)) (not shown), which can be shared among processor cores 2407 using known cache coherence techniques. In at least one embodiment, additionally included in processor(s) 2402 are register file(s) 2406, which can include different types of registers (e.g., integer registers, floating point registers, status registers, and instruction pointer registers) for storing different kinds of data.

[0351] In at least one embodiment, one or more processors 2402 are coupled with one or more interface buses 2410 for passing communication signals between processor 2402 and other components of system 2400, such as storage memory 2420, input devices 2424, and output devices 2426. In at least one embodiment, one or more input devices 2424 can include, without limitation, a keyboard, mouse, pen, voice input device, touch input device, etc. In at least one embodiment, one or more output devices 2426 can include, without limitation, a display, speakers, printer, etc.

[0352] In at least one embodiment, memory device 2420 can be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory device, a phase- change memory device, or some other memory device having suitable performance to serve as a processor memory. In at least one embodiment, memory device 2420 can operate as system memory for system 2400, for storing data 2422 and instructions 2421 for use when one or more processors 2402 executes an application or process. In at least one embodiment, memory controller 2416 also couples with an optional external graphics processor 2412, which can communicate with one or more graphics processors 2408 in processor 2402 to perform graphics and media operations.

[0353] In at least one embodiment, the platform controller hub 2430 enables peripheral devices to connect to the memory device 2420 and the processor 2402 via a high-speed I / O bus. In at least one embodiment, the I / O peripheral devices include, but are not limited to, an audio controller 2446, a network controller 2434, a firmware interface 2428, a wireless transceiver 2426, a touch sensor 2425, and a data storage device 2424 (e.g., a hard disk drive, flash memory, etc.). In at least one embodiment, the data storage device 2424 may be connected via a storage interface (e.g., SATA) or via a peripheral bus, such as a peripheral component interconnect bus (e.g., PCI, PCIe). In at least one embodiment, the touch sensor 2425 may include a touchscreen sensor, a pressure sensor, or a fingerprint sensor. In at least one embodiment, the wireless transceiver 2426 may be a Wi-Fi transceiver, a Bluetooth transceiver, or a mobile network transceiver, such as a 3G, 4G, or LTE transceiver. In at least one embodiment, the firmware interface 2428 enables communication with the system firmware and may be, for example, a Unified Extensible Firmware Interface (UEFI). In at least one embodiment, network controller 2434 can implement network connectivity to a wired network. In at least one embodiment, a high-performance network controller (not shown) is coupled to interface bus 2410. In at least one embodiment, audio controller 2446 is a multi-channel high-definition audio controller. In at least one embodiment, system 2400 includes an optional legacy I / O controller 2440 for coupling legacy (e.g., Personal System 2 (PS / 2)) devices to system 2400. In at least one embodiment, platform controller hub 2430 can also be connected to one or more Universal Serial Bus (USB) controllers 2442, which connect input devices such as keyboard and mouse 2443 combinations, camera 2444, or other USB input devices.

[0354] In at least one embodiment, instances of the memory controller 2416 and platform controller hub 2430 may be integrated into a discrete external graphics processor, such as external graphics processor 2412. In at least one embodiment, the platform controller hub 2430 and / or memory controller 2416 may be external to one or more processors 2402. For example, in at least one embodiment, system 2400 may include external memory controller 2416 and platform controller hub 2430, which may be configured as a memory controller hub and peripheral controller hub in a system chipset communicating with one or more processors 2402.

[0355] Inference and / or training logic 615 is used to perform inference and / or training operations associated with one or more embodiments. This document combines... FIG. 6B and / or FIG. 6ADetails regarding the inference and / or training logic 615 are provided. In at least one embodiment, some or all of inference and / or training logic 615 can be incorporated with graphics processor 2408. For example, in at least one embodiment, the training and / or inference techniques described herein can use one or more ALUs embodied in a 3D pipeline. Further, in at least one embodiment, the inference and / or training operations described herein can be accomplished with logic other than that shown. FIG. 6B or FIG. 24 In at least one embodiment, weight parameters can be stored in on-chip or off-chip memory and / or registers (shown or not) that configure ALUs of graphics processor 2408 to perform one or more machine learning algorithms, neural network architectures, use cases, or training techniques described herein.

[0356] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used with features of FIG. 25 and can be configured to receive sensor input from multiple sensors and can be trained to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor input to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor input can be correlated with different classes of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such different classes of sensor input can be indicative of a cooling demand, or a change thereof.

[0357] FIG. 6A is a block diagram of a processor 2500 having one or more processor cores 2502A-2502N, an integrated memory controller 2514, and an integrated graphics processor 2508, according to at least one embodiment. In at least one embodiment, processor 2500 can include additional cores, up to and including an additional core 2502N represented by a dashed lined in block. In at least one embodiment, each processor core 2502A-2502N includes one or more internal cache units 2504A-2504N. In at least one embodiment, each processor core can also include one or more shared cache units 2506. In at least one embodiment, graphics processor 2508 includes one or more graphics cores 1600.

[0358] In at least one embodiment, internal cache units 2504A-2504N and shared cache unit 2506 represent a cache memory hierarchy within processor 2500. In at least one embodiment, cache memory units 2504A-2504N can include at least one level of instruction and data caches within each processor core and one or more levels of shared mid-level cache, such as level 2 (L2), level 3 (L3), level 4 (L4), or other level of cache, with the highest level of cache prior to main memory being classified as an LLC. In at least one embodiment, cache coherency logic maintains coherency among the various cache units 2506 and 2504A-2504N.

[0359] In at least one embodiment, processor 2500 can also include a set of one or more bus controller units 2516 and system agent core 2510. In at least one embodiment, bus controller units 2516 manage a set of peripheral buses, such as one or more PCI or PCIe buses. In at least one embodiment, system agent core 2510 provides management functionality for the various processor components. In at least one embodiment, system agent core 2510 includes one or more integrated memory controllers 2514 to manage access to various external memory devices (not shown), such as one or more dynamic random access memory DRAM or static RAM (SRAM) devices.

[0360] In at least one embodiment, one or more processor cores 2502A-2502N include support for simultaneous multi-threading. In at least one embodiment, system agent core 2510 includes components for coordinating and operating cores 2502A-2502N during multi-threaded processing. In at least one embodiment, system agent core 2510 can additionally include a power control unit (PCU) including logic and components to regulate one or more power states of processor cores 2502A-2502N and graphics processor 2508.

[0361] In at least one embodiment, processor 2500 also includes graphics processor 2508 to perform graphics processing operations. In at least one embodiment, graphics processor 2508 couples with shared cache unit 2506 and system agent core 2510, including one or more integrated memory controllers 2514. In at least one embodiment, system agent core 2510 also includes a display controller 2511 to drive graphics processor output to one or more coupled displays. In at least one embodiment, display controller 2511 can also be a separate module coupled with graphics processor 2508 via at least one interconnect, or can be integrated within graphics processor 2508.

[0362] In at least one embodiment, ring based interconnect unit 2512 is used to couple internal components of processor 2500. In at least one embodiment, alternative interconnect units can be used such as a point-to-point interconnect, a switched interconnect, or other technology. In at least one embodiment, graphics processor 2508 is coupled with ring interconnect 2512 via I / O link 2513.

[0363] In at least one embodiment, I / O link 2513 represents at least one of a variety of I / O interconnects including a package I / O interconnect facilitating communication between various processor components and a high performance embedded memory module 2518 such as an eDRAM module. In at least one embodiment, each of processor cores 2502A-2502N and graphics processor 2508 uses embedded memory module 2518 as a shared last level cache.

[0364] In at least one embodiment, processor cores 2502A-2502N are homogeneous cores executing a common instruction set architecture. In at least one embodiment, processor cores 2502A-2502N are heterogeneous with respect to instruction set architecture (ISA) in that one or more processor cores 2502A-2502N execute a common instruction set while one or more other cores of processor cores 2502A-2502N execute a subset of the common instruction set or a different instruction set entirely. In at least one embodiment, processor cores 2502A-2502N are heterogeneous with respect to microarchitecture wherein one or more cores have a relatively high power consumption coupled with one or more power cores having a lower power consumption. In at least one embodiment, processor 2500 can be implemented on or as SoC integrated circuits.

[0365] Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 can be used in graphics processor 2508. FIG. 6B and / or FIG. 25 Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, part or all of inference and / or training logic 615 can be incorporated in graphics processor 2508. For example, in at least one embodiment, training and / or inferencing techniques described herein can use one or more ALUs embodied in 3D pipeline, graphics core 2502, shared function logic, or other logic in FIG. 6A In at least one embodiment, inferencing and / or training operations described herein can use other hardware elements in place of, or in addition to, graphics processor 2508 and / or inference and / or training logic 615. FIG. 6B or FIG. 25Logic outside of the illustrated logic to accomplish. In at least one embodiment, the weight parameters can be stored in on-chip or off-chip memory and / or registers (shown or not shown) that configure ALUs of processor 2500 to perform one or more machine learning algorithms, neural network architectures, use cases, or training techniques described herein.

[0366] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used in conjunction with features of FIG. 26 and can be configured to receive sensor inputs from multiple sensors and can be trained to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor inputs to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor inputs can be correlated to different classes of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such different classes of sensor input can be indicative of a cooling demand, or a change thereof.

[0367] FIG. 6A is a block diagram of a graphics processor 2600 that can be a discrete graphics processing unit, or can be graphics processor integrated with one or more processing cores. In at least one embodiment, graphics processor 2600 communicates with registers on graphics processor 2600, as well as with commands placed into memory, via a memory mapped I / O interface. In at least one embodiment, graphics processor 2600 includes a memory interface 2614 for accessing memory. In at least one embodiment, memory interface 2614 is an interface to local memory, one or more internal caches, one or more shared external caches, and / or to system memory. In at least one embodiment, graphics processor 2600 includes graphics core 1600.

[0368] In at least one embodiment, graphics processor 2600 also includes a display controller 2602 to drive display output data to a display device 2620. In at least one embodiment, display controller 2602 includes hardware for one or more overlay planes for compositing with video or user interface elements, and a combination of compositing layers of 2D and 3D graphics. In at least one embodiment, display device 2620 can be an internal or external display device. In at least one embodiment, display device 2620 is a head-mounted display device, such as a virtual reality (VR) display device or an augmented reality (AR) display device. In at least one embodiment, graphics processor 2600 includes a video codec engine 2606 to encode, decode, or transcode media into a compressed or encoded format for storage, transmission, or consumption. In at least one embodiment, video codec engine 2606 supports one or more video compression formats used in encoding or decoding video data. In at least one embodiment, video compression formats include Moving Picture Expert Group (MPEG) formats such as MPEG-2, Advanced Video Coding (AVC) formats such as H.264 / MPEG-4 AVC, and Society of Motion Picture and Television Engineers (SMPTE) 421M / VC-1, and Joint Photographic Experts Group (JPEG) and Motion JPEG (MJPEG) formats.

[0369] In at least one embodiment, graphics processor 2600 includes a block image transfer (BLIT) engine 2604 to perform two-dimensional (2D) rasterizer operations including, for example, bit-boundary block transfers. However, in at least one embodiment, 2D graphics operations are performed using one or more components of graphics processing engine (GPE) 2610. In at least one embodiment, GPE 2610 is a compute engine for performing graphics operations, including three-dimensional (3D) graphics operations and media operations.

[0370] In at least one embodiment, GPE 2610 includes a 3D pipeline 2612 for performing 3D operations, such as rendering three-dimensional graphics shapes representing 3D objects and scenes along with the lighting, shading, and material properties that affect the scene. In at least one embodiment, 3D pipeline 2612 includes programmable and fixed function elements to perform these operations. Although 3D pipeline 2612 can be used to perform media operations, in at least one embodiment GPE 2610 also includes a media pipeline 2616 to

[0371] In at least one embodiment, media pipeline 2616 includes fixed function or programmable logic for performing one or more specialized media operations on video data, such as video decode acceleration, video de-interlacing, and video encode acceleration. In at least one embodiment, media pipeline 2616 also includes thread spawning functionality to spawn threads for execution on 3D / Media sub-system 2615. In at least one embodiment, spawned threads execute computations for media operations in one or more graphics execution units included in 3D / Media sub-system 2615.

[0372] In at least one embodiment, 3D / Media sub-system 2615 includes logic to execute threads spawned by 3D pipeline 2612 and media pipeline 2616. In at least one embodiment, 3D pipeline 2612 and media pipeline 2616 send thread execution requests to 3D / Media sub-system 2615, which includes thread dispatch logic to arbitrate various requests and dispatch them for execution on available thread execution resources. In at least one embodiment, execution resources include an array of graphics execution units to process 3D and media threads. In at least one embodiment, 3D / Media sub-system 2615 includes one or more internal caches to cache it thread instructions and data. In at least one embodiment, sub-system 2615 also includes shared memory, including registers and

[0373] Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 can be used in graphics processing unit 2600. FIG. 6B and / or FIG. 6A Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, portions or all of inference and / or training logic 615 can be incorporated into graphics processing unit 2600. For example, in at least one embodiment, training and / or inferencing techniques described herein can use one or more ALUs included in 3D pipeline 2612. Further, in at least one embodiment, inferencing and / or training operations described herein can be done using logic other than that illustrated in FIG. 6L. In at least one embodiment, weight parameters can be stored in on-chip or off-chip memory and / or registers (shown or not) that configure ALUs of graphics processing unit 2600 to perform one or more machine learning algorithms, neural network architectures, use cases, or training techniques described herein. FIG. 6B or FIG. 26 Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, portions or all of inference and / or training logic 615 can be incorporated into graphics processing unit 2600. For example, in at least one embodiment, training and / or inferencing techniques described herein can use one or more ALUs included in 3D pipeline 2612. Further, in at least one embodiment, inferencing and / or training operations described herein can be done using logic other than that illustrated in FIG. 6L. In at least one embodiment, weight parameters can be stored in on-chip or off-chip memory and / or registers (shown or not) that configure ALUs of graphics processing unit 2600 to perform one or more machine learning algorithms, neural network architectures, use cases, or training techniques described herein.

[0374] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be configured to perform one or more of the techniques described in connection with FIGS. 6A-6J. FIG. 27features are used in conjunction, and can be configured to receive sensor inputs from multiple sensors, and can be trained to infer coolant demand. In at least one embodiment, inference and / or training logic 615 is capable of inferring coolant demand with information from historical cooling demand and historical sensor inputs. In at least one embodiment, inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor inputs can be correlated with different classes of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such different classes of sensor input can be indicative of a cooling demand, or a change thereof.

[0375] FIG. 26 is a block diagram of a graphics processing engine 2710 of a graphics processing unit according to at least one embodiment. In at least one embodiment, a graphics processing engine (GPE) 2710 is a version of GPE 2610 shown and described in FIG. 27. FIG. 6A In at least one embodiment, media pipeline 2716 is optional and can not be explicitly included in GPE 2710. In at least one embodiment, a separate media and / or image processor is coupled to GPE 2710.

[0376] In at least one embodiment, GPE 2710 is coupled to or includes a command streamer 2703 that provides a command stream to 3D pipeline 2712 and / or media pipeline 2716. In at least one embodiment, command streamer 2703 is coupled to memory, which can be system memory, or one or more of internal cache memory and shared cache memory. In at least one embodiment, command streamer 2703 receives commands from memory and sends commands to 3D pipeline 2712 and / or media pipeline 2716. In at least one embodiment, commands are instructions, primitives, or micro-operations fetched from a ring buffer that stores commands for 3D pipeline 2712 and media pipeline 2716. In at least one embodiment, ring buffer can also include batch command buffers that store batches of multiple commands. In at least one embodiment, commands for 3D pipeline 2712 can also include references to data stored in memory, such as, but not limited to, vertex and geometry data for 3D pipeline 2712 and image data and memory objects for media pipeline 2716. In at least one embodiment, 3D pipeline 2712 and media pipeline 2716 process commands and data by executing them on one or more execution units of graphics core array 2714. In at least one embodiment, graphics core array 2714 includes one or more graphics core blocks (e.g., one or more graphics cores 2715A, one or more graphics cores 2715B), each including one or more graphics cores. In at least one embodiment, graphics cores 2715A, 2715B can be referred to as execution units (“EUs”). In at least one embodiment, each graphics core includes a set of graphics execution resources including general and graphics specific execution logic to perform graphics and compute operations in accordance with various embodiments described herein. In at least one embodiment, fixed function and / or machine learning and artificial intelligence acceleration logic includes FIG. 6B and FIG. 6A inference and / or training logic 615.

[0377] In at least one embodiment, 3D pipeline 2712 includes fixed function and programmable logic to process one or more shader programs, such as vertex shaders, geometry shaders, pixel shaders, fragment shaders, compute shaders, or other shader programs, by processing instructions and dispatching execution threads to graphics core array 2714. In at least one embodiment, graphics core array 2714 provides unified execution resources to be used by all types of shader programs in a multi-threaded environment. In at least one embodiment, multipurpose execution logic (e.g., execution units) within one or more graphics cores 2715A-2715B across graphics core array 2714 includes support for variable length

[0378] In at least one embodiment, graphics core array 2714 also includes execution logic to perform media functions, such as video and / or image processing. In at least one embodiment, execution units include fixed function or programmable logic that is optimized to perform

[0379] In at least one embodiment, output data generated by threads executing on graphics core array 2714 can output data to memory in a unified return buffer (URB) 2718. In at least one embodiment, URB 2718 can store data for multiple threads. In at least one embodiment, URB 2718 can be used to send data between different threads executing on graphics core array 2714. In at least one embodiment, URB 2718 can also be used for synchronization between threads on graphics core array 2714 and fixed function logic within shared function logic 2720.

[0380] In at least one embodiment, graphics core array 2714 is scalable, such that graphics core array 2714 includes variable numbers of graphics cores, each of which includes variable numbers of execution units based on target performance and power levels of GPE 2710. In at least one embodiment, execution resources are dynamically scalable, such that execution resources can be enabled or disabled as needed.

[0381] In at least one embodiment, graphics core array 2714 is coupled to shared function logic 2720, which includes a number of resources shared among graphics cores in graphics core array 2714. In at least one embodiment, shared functions performed by shared function logic 2720 are embodied in hardware logic units that provide specialized supplemental functionality to graphics core array 2714. In at least one embodiment, shared function logic 2720 includes, without limitation, sampler units 2721, math units 2722, and inter-thread communication (ITC) logic 2723. In at least one embodiment, one or more caches 2725 are included in or coupled to shared function logic 2720.

[0382] In at least one embodiment, shared functions are used if demand for specialized functionality is insufficient to include in graphics core array 2714. In at least one embodiment, a single instantiation of specialized functionality is used in shared function logic 2720 and shared among other execution resources within graphics core array 2714. In at least one embodiment, particular shared functions within shared function logic 2720 that are used extensively by graphics core array 2714 can be included within shared function logic 2726 within graphics core array 2714. In at least one embodiment, shared function logic 2726 within graphics core array 2714 can include some or all of the logic within shared function logic 2720. In at least one embodiment, all logical elements within shared function logic 2720 can be replicated within shared function logic 2726 of graphics core array 2714. In at least one embodiment, shared function logic 2720 is excluded in favor of shared function logic 2726 within graphics core array 2714.

[0383] Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6A and / or 6B. In examples in which inference and / or training logic 615 are used for inferencing only, inference logic can omit components described below that are used for training. FIG. 6B and / or FIG. 27 Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6A and / or 6B. In examples in which inference and / or training logic 615 are used for inferencing only, inference logic can omit components described below that are used for training. FIG. 6A In at least one embodiment, inference and / or training operations described herein can be performed by one or more ALUs embodied in 3D pipeline 2712, one or more graphics cores 2715, shared function logic 2726, shared function logic 2720, or other logic within graphics processor 2710. Moreover, in at least one embodiment, inference and / or training operations described herein can be performed using hardware other than FIG. 6B or FIG. 27Logic outside of the illustrated logic to accomplish. In at least one embodiment, the weight parameters can be stored in on-chip or off-chip memory and / or registers (shown or not shown) that configure ALUs of graphics processor 2710 to perform one or more machine learning algorithms, neural network architectures, use cases, or training techniques described herein.

[0384] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used in conjunction with features of FIG. 28 and can be configured to receive sensor input from multiple sensors and can be trained to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor input to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor input can be correlated to a different class of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such a different class of sensor input can be indicative of a cooling demand, or a change thereof.

[0385] FIG. 6A is a block diagram of hardware logic of a graphics processor core 2800 in accordance with at least one embodiment described herein. In at least one embodiment, graphics processor core 2800 includes graphics core 1600. In at least one embodiment, graphics processor core 2800 is included within a graphics core array. In at least one embodiment, graphics processor core 2800 (sometimes referred to as a core slice) can be one or more graphics cores within a modular graphics processor. In at least one embodiment, graphics processor core 2800 is an example of one graphics core slice, and graphics processors described herein can include multiple graphics core slices based on target power and performance envelopes. In at least one embodiment, each graphics core 2800 can include fixed function blocks 2830 coupled with multiple sub-cores 2801A-2801F (also referred to as sub-slices) that include modular blocks of general-purpose and fixed function logic.

[0386] In at least one embodiment, fixed function blocks 2830 include geometry and fixed function pipeline 2836 that can be shared by all sub-cores in graphics processor 2800, for example, in lower performance and / or lower power graphics processor implementations. In at least one embodiment, geometry and fixed function pipeline 2836 includes a 3D fixed function pipeline, a video front-end unit, a thread generator and thread dispatcher, and a unified return buffer manager that manages a unified return buffer.

[0387] In at least one embodiment, fixed function blocks 2830 also include a graphics SoC interface 2837, a graphics microcontroller 2838, and a media pipeline 2839. In at least one embodiment, graphics SoC interface 2837 provides an interface between graphics core 2800 and other processor cores in a system on a chip (SoC) integrated circuit. In at least one embodiment, graphics microcontroller 2838 is a programmable sub-processor that is configurable for managing graphics processing engine 2800. In at least one embodiment, graphics microcontroller 2838 includes programmable logic to implement

[0388] In at least one embodiment, SoC interface 2837 enables graphics core 2800 to communicate with general application processor cores (e.g., CPUs) and / or other components within an SoC, including memory hierarchy elements such as shared last level cache, system RAM, and / or embedded on-chip or package on-lens DRAM. In at least one embodiment, SoC interface 2837 can also enable communication with fixed function devices within an SoC, such as a camera image signal processor (ISP) and / or other components. In at least one embodiment, SoC interface 2837 enables use of and / or implements global memory atoms that can be shared between graphics core 2800 and a CPU within an SoC. In at least one embodiment, graphics SoC interface 2837 also implements power management controls for graphics processor core 2800 and enables an interface between a clock domain of a graphics processor core 2800 and other clock domains within an SoC. In at least one embodiment, SoC interface 2837 enables receipt of a command buffer from a command streamer and global thread dispatcher that is configured to supply threads and instructions to each of one or more graphics cores within a graphics processor. In at least one embodiment, when media operations are to be performed, commands and instructions can be dispatched to media pipeline 2839, or when graphics processing operations are to be performed, commands and instructions can be dispatched to geometry and fixed function pipeline (e.g., geometry and fixed function pipeline 2836, and / or geometry and fixed function pipeline 2814).

[0389] In at least one embodiment, graphics microcontroller 2838 can be configured to perform various scheduling and management tasks for graphics core 2800. In at least one embodiment, graphics microcontroller 2838 can perform graphics and / or compute workload scheduling on individual graphics processing engines within execution unit (EU) arrays 2802A-2802F, 2804A-2804F of sub-cores 2801A-2801F. In at least one embodiment, host software executing on a CPU core of an SoC including graphics core 2800 can submit workloads to one of multiple graphics processor paths, which invoke scheduling operations on appropriate graphics engines. In at least one embodiment, scheduling operations include determining which workload to run next, submitting the workload to a command streamer, pre-empting existing workloads running on engines, monitoring progress of workloads, and notifying host software when workloads are complete. In at least one embodiment, graphics microcontroller 2838 can also facilitate low power or idle states for graphics core 2800, providing the ability to save and restore registers across low power state transitions independent of operating system and / or graphics driver software on the system.

[0390] In at least one embodiment, graphics core 2800 can have up to N more or less modular sub-cores than shown. For each set of N sub-cores, graphics core 2800 can also include shared function logic 2810, shared and / or cache memory 2812, geometry / fixed function pipeline 2814, and additional fixed function logic 2816 in at least one embodiment, which are used to accelerate various graphics and compute processing operations. In at least one embodiment, shared function logic 2810 can include logic units (e.g., samplers, math, and / or inter-thread communication logic) that can be shared by each N sub-core within graphics core 2800. In at least one embodiment, shared and / or cache memory 2812 can be a last level cache for the N sub-cores 2801A-2801F within graphics core 2800, and can also be used as shared memory that can be accessed by multiple sub-cores. In at least one embodiment, geometry / fixed function pipeline 2814 can be included instead of geometry / fixed function pipeline 2836 within fixed function block 2830, and can include similar logic units.

[0391] In at least one embodiment, graphics core 2800 includes additional fixed function logic 2816 which can include various fixed function acceleration logic to be utilized by graphics core 2800. In at least one embodiment, additional fixed function logic 2816 includes additional geometry pipeline for use in position only shading. In position only shading, there are at least two geometry pipelines, a full geometry pipeline within geometry and fixed function pipeline 2814, 2836 and a cull pipeline, which is an additional geometry pipeline that can be included in additional fixed function logic 2816. In at least one embodiment, cull pipeline is a trimmed down version of full geometry pipeline. In at least one embodiment, full and cull pipelines can execute different instances of an application, each with separate contexts. In at least one embodiment, position only shading can hide long cull runs of triangles that are discarded, resulting in earlier completion of shading in some cases. For example, in at least one embodiment, cull pipeline logic in additional fixed function logic 2816 can execute position shaders in parallel with a main application and often generate critical results faster than a full pipeline because cull pipeline takes position attributes of vertices and shades them without needing to perform rasterization and render pixels to a frame buffer. In at least one embodiment, cull pipeline can use generated critical results to compute visibility information for all triangles regardless of whether these triangles are culled or not. In at least one embodiment, full pipeline, which in this case can be referred to as a replay pipeline, can consume visibility information to skip culled triangles to only shade visible triangles that are finally passed to a rasterization stage.

[0392] In at least one embodiment, additional fixed function logic 2816 can also include machine learning acceleration logic, such as fixed function matrix multiplication logic for an implementation that includes optimizations for machine learning training or inferencing.

[0393] In at least one embodiment, within each graphics sub-core 2801A-2801F includes a set of execution resources which can be used to perform graphics, media, and compute operations in response to requests by graphics pipeline, media pipeline, or shader program. In at least one embodiment, graphics sub-cores 2801A-2801F include multiple arrays of EU’s 2802A-2802F, 2804A-2804F, thread dispatch and inter-thread communication (TD / IC) logic 2803A-2803F, 3D (e.g., texture) samplers 2805A-2805F, media samplers 2806A-2806F, shader processors 2807A-2807F, and shared local memory (SLM) 2808A-2808F. In at least one embodiment, EU arrays 2802A-2802F, 2804A-2804F each include multiple execution units, which are general-purpose graphics processing units capable of performing floating-point and integer / fixed-point logic operations in service of a graphics, media, or compute operation, including graphics, media, or compute shader programs. In at least one embodiment, TD / IC logic 2803A-2803F performs local thread dispatch and thread control operations for execution units within a sub-core and facilitate communication between threads executing on execution units of the sub-core. In at least one embodiment, 3D samplers 2805A-2805F can read texture or other 3D graphics related data into memory. In at least one embodiment, 3D samplers can read texture data differently based on a configured sample state and a texture format associated with a given texture. In at least one embodiment, media samplers 2806A-2806F can perform similar read operations based on a type and format associated media data. In at least one embodiment, each graphics sub-core 2801A-2801F can alternatively include unified 3D and media samplers. In at least one embodiment, threads executing on execution units within each of the sub-cores 2801A-2801F can make use of shared local memory 2808A-2808F within each sub-core for storage of thread private data and / or shared memory for storage of shared data amongst threads executing on execution units within an EU array 2802A-2802F, 2804A-2804F of the respective sub-cores 2801A-2801F.

[0394] Inference and / or training logic 615 are used to perform inferencing and / or training operations associated with one or more embodiments. Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, inference and / or training logic 615 are used in conjunction with components of FIG. 6B and / or FIG. 28 Details regarding inference and / or training logic 615 are provided below in conjunction with FIGS. 6L and / or 6M. In at least one embodiment, portions or all of inference and / or training logic 615 can be incorporated in graphics processor 2800. For example, in at least one embodiment, training and / or inference techniques described herein can be performed by 3D pipeline, graphics microcontroller 2838, geometry and fixed function pipeline 2814 and 2836, or FIG. 6Aone or more ALUs embodied in other logic in the ALU(s) 2120. Additionally, in at least one embodiment, inference and / or training operations described herein can be done using logic other than the logic 2120 shown. In at least one embodiment, weight parameters can be stored in on-chip or off-chip memory and / or registers (shown or not) that configure ALUs of graphics processor 2100 to perform one or more machine learning algorithms, neural network architectures, use cases, or training techniques described herein. FIG. 6B or FIG. 28 In at least one embodiment, weight parameters can be stored in on-chip or off-chip memory and / or registers (shown or not) that configure ALUs of graphics processor 2800 to perform one or more machine learning algorithms, neural network architectures, use cases, or training techniques described herein.

[0395] In at least one embodiment, one or more neural networks of inference and / or training logic 615 can be used in conjunction with features of FIGS. 29A-29B and can be configured to receive sensor input from multiple sensors and can be trained to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can utilize information from historical cooling demand and historical sensor input to infer coolant demand. In at least one embodiment, inference and / or training logic 615 can infer a change in cooling demand. In at least one embodiment, sensor input can be correlated to a different class of cooling demand for each different sensor input. In at least one embodiment, a new sensor input classified in such a different class of sensor input can indicate a cooling demand, or a change in cooling demand.

[0396] FIG. 29A Thread execution logic 2900 is shown including an array of processing elements that include graphics processor cores, according to at least one embodiment. FIG. 29B At least one embodiment is shown in which thread execution logic 2900 is used. FIG. 29A Exemplary internal details of graphics execution unit 2908 are shown, according to at least one embodiment.

[0397] As FIG. 29BAs shown in FIG. 29, in at least one embodiment, thread execution logic 2900 includes shader processor 2902, thread dispatcher 2904, instruction cache 2906, array of programmable execution units including a plurality of execution units 2907A-2907N and 2908A-2908N, sampler 2910, data cache 2912, and data port 2914. In at least one embodiment, array of programmable execution units can dynamically expand and / or contract, for example, based on the computational requirements of a workload. In at least one embodiment, the array of programmable execution units are interconnected through an interconnection structure, for example, a crossbar, to enable communications between execution units for parallel processing of multiple threads. In at least one embodiment, thread execution logic 2900 includes one or more connections to memory, for example, system memory or cache memory, via instruction cache 2906, data port 2914, sampler 2910, and one or more of execution units 2907 or 2908. In at least one embodiment, each execution unit, for example 2907A, is a programmable streaming processor that is capable of processing a large number of threads simultaneously with each thread handling multiple data elements in parallel. In at least one embodiment, array of execution units 2907 and / or 2908 are extensible so as to include any number of individual execution units.

[0398] In at least one embodiment, execution units 2907 and / or 2908 are primarily used for executing shader programs. In at least one embodiment, shader processor 2902 can process various shader programs and dispatch execution threads associated with shader programs to execution units 2907 and / or 2908 via thread dispatcher 2904. In at least one embodiment, thread dispatcher 2904 includes logic to arbitrate thread initiation requests from the graphics and media pipelines and instantiate the requested threads on one or more of execution units 2907 and / or 2908. For example, in at least one embodiment, a geometry pipeline can dispatch a vertex, tessellation or geometry shader to thread execution logic for processing. In at least one embodiment, thread dispatcher 2904 can also handle runtime thread spawning instructions found in executed shader programs.

[0399] In at least one embodiment, execution units 2907 and / or 2908 support a instruction set that includes native support for many standard 3D graphics shader instructions, such that a shader program from, for example, OpenGL or Direct 3D, can be executed with little or no translation from the original program. In at least one embodiment, execution units 2907 and / or 2908 support vertex and geometry processing (e.g., vertex programs, geometry programs, and / or vertex shaders), pixel processing (e.g., pixel shaders, fragment shaders), and general-purpose processing (e.g., compute and media shaders). In at least one embodiment, each execution unit 2907 and / or 2908 includes one or more arithmetic logic units (ALUs) to perform integer and floating-point operations. In at least one embodiment, execution units 2907 and / or 2908 include fixed function execution units for performing graphics-de specific operations such as copy, cube map project, texture attribute traversal, pixel value interpolation, bilinear filtering including min / max, cubic environment map filtering, cubic environment map projection, perspective- correct polynomial texture mapping, depth texturing, point sprite rendering, and particle rendering functions. In at least one embodiment, execution units 2907 and / or 2908 include a number of general-purpose execution units (ALUs) which would be dynamically configured by microcode at runtime to support one or more graphics-de specific and / or general-purpose libraries, APIs, or function calls. In at least one embodiment, execution units 2907 and / or 2908 also include built-in

[0400] In at least one embodiment, each of execution units 2907 and / or 2908 is to operate on arrays of data elements. In at least one embodiment, the number of data elements is the “execution size,” or number of channels, of the instruction. In at least one embodiment, execution channels refer to logical partitions of the execution resources within an execution unit, which can write different data element values. In at least one embodiment, an execution channel can be interpreted as a source or destination of data. In at least one embodiment, execution unit 2907 and / or 2908 supports integer and floating-point data types.

[0401] In at least one embodiment, the execution unit instruction set includes SIMD instructions. In at least one embodiment, individual data elements can be stored as a packed data type within a register and the execution unit will process the packed data type as multiple instances of the SIMD instruction. For example, if a 256-bit register is stored with four 64-bit packed data elements and an execution unit receives a single 64-bit SIMD instruction, it will process that instruction four times, once on each 64-bit packed data element. In at least one embodiment, any data element width and number of data elements supported by an execution unit can be used. In at least one embodiment, data elements can be 8-bits (1 byte), 16-bits (2 bytes), 32-bits (4 bytes), 64-bits (8 bytes), or any other size.

[0402] In at least one embodiment, one or more execution units can be combined in a fused execution unit 2909A-2909N with thread control logic (2911A-2911N) shared by the fused EU, such as fusing execution unit 2907A with execution unit 2908A into fused execution unit 2909A. In at least one embodiment, multiple EUs can be fused into an EU group. In at least one embodiment, each EU in a fused EU group can be configured to execute a separate SIMD hardware thread, where a number of EUs in a fused EU group can vary based on implementation. In at least one embodiment, each EU can execute a variety of SIMD widths including, but not limited to, SIMD8, SIMD16, and SIMD32. In at least one embodiment, each fused graphics execution unit 2909A-2909N includes at least two execution units. For example, in at least one embodiment, fused execution unit 2909A includes first EU 2907A, second EU 2908A, and thread control logic 2911A shared by first EU 2907A and second EU 2908A. In at least one embodiment, thread control logic 2911A controls threads executing on fused execution unit 2909A, allowing each EU within fused execution units 2909A-2909N to use a common instruction pointer register for execution.

[0403] In at least one embodiment, one or more internal instruction caches (e.g., 2906) are included in thread execution logic 2900 to cache thread instructions for execution units. In at least one embodiment, one or more data caches (e.g., 2912) are included to cache thread data during thread execution. In at least one embodiment, a sampler 2910 is included to provide texture sampling for 3D operations and media sampling for media operations. In at least one embodiment, sampler 2910 includes specialized texture or media sampling functionality to process texture or media data during sampling prior to outputting sampled data to execution units.

[0404] During execution, in at least one embodiment, graphics and media pipelines send thread initiation requests to thread execution logic 2900 via thread spawn and dispatch logic. In at least one embodiment, once a set of geometric objects has been processed and rasterized into pixel data, pixel processor logic (e.g., pixel shader logic, fragment shader logic, etc.) within shader processor 2902 is invoked to further compute output information and cause results to be written to an output surface (e.g., a color buffer, a depth buffer, a stencil buffer, etc.). In at least one embodiment, pixel or fragment shaders compute values of various vertex attributes to be interpolated across a rasterized object. In at least one embodiment, pixel processor logic within shader processor 2902 then executes a pixel or fragment shader program provided by an application programming interface (API). In at least one embodiment, to execute a shader program, shader processor 2902 dispatches threads to execution units (e.g., 2908A) via thread dispatcher 2904. In at least one embodiment, shader processor 2902 uses texture sampling logic in sampler 2910 to access texture data stored in a texture map in memory. In at least one embodiment, arithmetic operations on texture data and input geometry data compute pixel color data for each geometric fragment, or discard one or more pixels for no further processing.

[0405] In at least one embodiment, data port 2914 provides a memory access mechanism for thread execution logic 2900 to output processed data to memory for further pr...

Claims

1. A data center cooling system, comprising: A first interface flow controller, including a sensor and associated with a first server tray of a rack, is configured to receive sensor input and communicate with a second interface flow controller via a communication line therebetween. The second interface flow controller is associated with a coolant distribution unit (CDU) to balance the coolant flow supplied from the CDU to one or more second server trays, in part based on changes in coolant flow to the first server tray as indicated by the sensor input.

2. The data center cooling system according to claim 1, further comprising: At least one processor, associated with the first interface flow controller, enables the first interface flow controller to receive the sensor input and to communicate with the second interface flow controller via the communication line. The at least one processor is configured to determine, in part, based on the sensor input, the disconnection of the first server tray from the first interface flow controller, and to enable the second interface flow controller to cause a balance of the coolant flow from the CDU to the one or more second server trays.

3. The data center cooling system of claim 1, wherein the first interface flow controller is associated with the inlet of the first server tray to cause the change in coolant flow by stopping the coolant flow to the first server tray, and wherein the second interface flow controller is associated with the outlet of the CDU to cause a balance in the coolant flow to the one or more second server trays.

4. The data center cooling system according to claim 1, further comprising: The sensor is adapted to provide sensor input to at least one processor of the first interface flow controller, the provided sensor input being used to indicate disconnection of the first server tray from the first interface flow controller, the disconnection being used to realize the change in coolant flow.

5. The data center cooling system of claim 4, wherein the change in coolant flow is a cessation of the coolant flow through the first interface flow controller to the first server tray.

6. The data center cooling system according to claim 1, further comprising: At least one processor is configured to determine, in part based on the sensor input, that the first server tray of the rack is disconnected from the first interface flow controller, the disconnection causing the change in the coolant flow.

7. The data center cooling system according to claim 1, further comprising: At least one processor is configured to determine a balance of the coolant flow supplied from the CDU to the one or more second server trays, the balance of the coolant flow being associated with a flow rate or volume intended for the one or more second server trays prior to the first server tray being disconnected to cause the change in the coolant flow to the first server tray.

8. The data center cooling system according to claim 1, further comprising: The second interface flow controller is adapted to provide the coolant flow at a first flow rate or velocity to the first server tray and a plurality of auxiliary server trays before disconnecting the first server tray to cause the change in the coolant flow, wherein the change is associated with reducing the first flow rate or velocity to provide a second flow rate or velocity from the second interface flow controller to the one or more second server trays.

9. The data center cooling system according to claim 1, further comprising: One or more neural networks are used to receive the sensor inputs and infer the changes in the coolant flow to the first server tray, the one or more neural networks being trained using previous sensor inputs and previous changes in the coolant flow.

10. The data center cooling system of claim 1, wherein the balance of the coolant flow provided from the CDU is a first flow rate or flow rate to the rack after the first server tray is disconnected from the first interface flow controller, the first flow rate or flow rate being a relative measurement of a second flow rate or flow rate provided before the first server tray and the first interface flow controller are disconnected.

11. A processor comprising one or more circuits and associated with a first interface flow controller, the processor being configured to receive sensor input from a sensor of the first interface flow controller and to communicate with a second interface flow controller via a communication line therebetween, the second interface flow controller being associated with a coolant distribution unit (CDU) to balance the coolant flow from the CDU to the second server tray in part based on changes in coolant flow to a first server tray as indicated by the sensor input.

12. The processor of claim 11, further comprising: The output is used to provide a signal to one or more of the first interface flow controller or the second interface flow controller via the communication line in response to the change in the coolant flow indicated by the sensor input.

13. The processor of claim 11, further comprising: Input, for receiving sensor input from the sensor, the sensor input being used in part based on continuous monitoring of the sensor input performed by the processor to determine the change in the coolant flow to the first server tray.

14. The processor of claim 13, further comprising: One or more neural networks are used to receive the sensor inputs and infer the changes in the coolant flow to the first server tray, the one or more neural networks being trained using previous sensor inputs and previous changes in the coolant flow.

15. The processor of claim 13, further comprising: At least one logic unit is configured to determine, in part, the change in the coolant flow to the first server tray based on continuous monitoring of the sensor input.

16. A method for a data center cooling system, comprising: A first interface flow controller is provided, which includes sensors and is associated with a first server tray in the rack; This enables the first interface flow controller to receive sensor input and communicate with the second interface flow controller through the communication line between them. Associate the second interface flow controller with the coolant distribution unit (CDU); as well as The second interface flow controller partially balances the coolant flow supplied from the CDU to one or more second server trays based on changes in the coolant flow to the first server tray as indicated by the sensor input.

17. The method of claim 16, further comprising: Using at least one processor, based in part on the change in the coolant flow, it is determined from the sensor input that a disconnection associated with the first interface flow controller has occurred; as well as This enables the second interface flow controller to cause a balance in the coolant flow from the CDU to the one or more second server trays.

18. The method of claim 16, further comprising: When the first server tray is disconnected from the first interface flow controller, the sensor provides sensor input to at least one processor, the sensor input being used to enable the second interface flow controller to cause the change in the coolant flow.

19. The method of claim 16, further comprising: Associate at least one processor with the first interface flow controller; The at least one processor enables the first interface flow controller to receive the sensor input and to communicate with the second interface flow controller via the communication line; The disconnection of the first server tray from the first interface flow controller is determined by the at least one processor in part based on the sensor input indicating the change in the coolant flow; as well as The at least one processor enables the second interface flow controller to cause a balance in the coolant flow from the CDU to the one or more second server trays.

20. The method of claim 16, further comprising: The sensor provides a sensor input to at least one processor located within the first interface flow controller, indicating that the first server tray is disconnected from the first interface flow controller; as well as The coolant flow is balanced by the second interface flow controller and in part based on the input from the at least one processor to the second interface flow controller.

Images