ES2933675T3 - Sistemas, métodos y aparatos para informática heterogénea - Google Patents

Sistemas, métodos y aparatos para informática heterogénea Download PDF

Info

Publication number
ES2933675T3
ES2933675T3 ES16925260T ES16925260T ES2933675T3 ES 2933675 T3 ES2933675 T3 ES 2933675T3 ES 16925260 T ES16925260 T ES 16925260T ES 16925260 T ES16925260 T ES 16925260T ES 2933675 T3 ES2933675 T3 ES 2933675T3
Authority
ES
Spain
Prior art keywords
memory
descriptor
accelerator
completion
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES16925260T
Other languages
English (en)
Inventor
Rajesh M Sankaran
Gilbert Neiger
Narayan Ranganathan
Doren Stephen R Van
Joseph Nuzman
Niall D Mcdonnell
Michael A O'hanlon
Lokpraveen B Mosur
Tracy Garrett Drysdale
Eriko Nurvitadhi
Asit K Mishra
Ganesh Venkatesh
Deborah T Marr
Nicholas P Carter
Jonathan D Pearce
Edward T Grochowski
Richard J Greco
Robert Valentine
Jesus Corbal
Thomas D Fletcher
Dennis R Bradford
Dwight P Manley
Mark J Charney
Jeffrey J Cook
Paul Caprioli
Koichi Yamada
Kent D Glossop
David B Sheffield
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Application granted granted Critical
Publication of ES2933675T3 publication Critical patent/ES2933675T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/10—Complex mathematical operations
    • G06F17/16—Matrix or vector computation, e.g. matrix-matrix or matrix-vector multiplication, matrix factorization
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/3001—Arithmetic instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/3001—Arithmetic instructions
    • G06F9/30014—Arithmetic instructions with variable precision
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30036—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30036—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations
    • G06F9/30038—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations using a mask
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory
    • G06F9/30047—Prefetch instructions; cache control instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/30087—Synchronisation or serialisation instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G06F9/3009—Thread control instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/3017—Runtime instruction translation, e.g. macros
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30181—Instruction operation extension or modification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30181—Instruction operation extension or modification
    • G06F9/30189—Instruction operation extension or modification according to execution mode, e.g. mode flag
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3824—Operand accessing
    • G06F9/383—Operand prefetching
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3824—Operand accessing
    • G06F9/3834—Maintaining memory consistency
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3842—Speculative instruction execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3854—Instruction completion, e.g. retiring, committing or graduating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3854—Instruction completion, e.g. retiring, committing or graduating
    • G06F9/3858—Result writeback, i.e. updating the architectural state or memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3854—Instruction completion, e.g. retiring, committing or graduating
    • G06F9/3858—Result writeback, i.e. updating the architectural state or memory
    • G06F9/38585—Result writeback, i.e. updating the architectural state or memory with result invalidation, e.g. nullification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3861—Recovery, e.g. branch miss-prediction, exception handling
    • G06F9/3863—Recovery, e.g. branch miss-prediction, exception handling using multiple copies of the architectural state, e.g. shadow registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3877—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3887—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple data lanes [SIMD]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3888—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple threads [SIMT] in parallel
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45583—Memory management, e.g. access or allocation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0026—PCI express
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Computational Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Algebra (AREA)
  • Databases & Information Systems (AREA)
  • Advance Control (AREA)
  • Executing Machine-Instructions (AREA)
  • Computer Hardware Design (AREA)
  • Devices For Executing Special Programs (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Treatment Of Liquids With Adsorbents In General (AREA)
  • Steroid Compounds (AREA)
  • Image Processing (AREA)
  • Multi Processors (AREA)
  • Stored Programmes (AREA)

Abstract

Se describen realizaciones de sistemas, métodos y aparatos para computación heterogénea. En algunas realizaciones, un programador heterogéneo de hardware envía instrucciones para su ejecución en uno o más de la pluralidad de elementos de procesamiento heterogéneos, correspondiendo las instrucciones a un fragmento de código para ser procesado por uno o más de la pluralidad de elementos de procesamiento heterogéneos, donde las instrucciones son nativas instrucciones a al menos uno de uno o más de la pluralidad de elementos de procesamiento heterogéneos. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Sistemas, métodos y aparatos para informática heterogénea
Campo técnico
La presente divulgación se refiere en general al campo de los dispositivos informáticos y, más particularmente, a los métodos, dispositivos y sistemas informáticos heterogéneos.
Antecedentes
En los ordenadores de hoy en día, las CPU realizan tareas informáticas de propósito general, tales como la ejecución de software de aplicación y sistemas operativos. Las tareas informáticas especializadas, tales como el procesamiento de gráficos e imágenes, se gestionan por procesadores gráficos, procesadores de imágenes, procesadores de señales digitales y aceleradores de función fija. En las máquinas heterogéneas de hoy en día, cada tipo de procesador se programa de forma diferente.
La era del procesamiento de grandes cantidades de datos exige un mayor rendimiento con menos energía en comparación con los procesadores de propósito general de hoy en día. Los aceleradores (unidades de funciones fijas personalizadas o unidades programables a medida, por ejemplo) están ayudando a satisfacer estas demandas. Dado que este campo está experimentando una rápida evolución tanto de los algoritmos como de las cargas de trabajo, el conjunto de aceleradores disponibles es difícil de predecir a priori y es muy probable que diverja entre las unidades de stock dentro de una generación de productos y que evolucione junto con las generaciones de productos.
El documento WO 2013/101139 A1 describe un procesador de múltiples núcleos con un primer y segundo grupo de núcleos. El segundo grupo puede ser de una arquitectura de conjunto de instrucciones (ISA) diferente a la del primer grupo o del mismo conjunto ISA, pero con un nivel de soporte de potencia y rendimiento diferente, y es transparente para un sistema operativo (SO). El proceso incluye además una unidad de migración que maneja las solicitudes de migración para un número de escenarios diferentes y provoca un cambio de contexto para migrar dinámicamente un proceso del segundo núcleo a un primer núcleo del primer grupo. Este cambio de contexto dinámico basado en el hardware puede ser transparente para el SO.
Breve descripción de los dibujos
Las realizaciones se entenderán fácilmente por la siguiente descripción detallada en conjunto con los dibujos adjuntos. Para facilitar esta descripción, los números de referencia similares designan elementos estructurales similares. Las realizaciones se ilustran a modo de ejemplo, y no a modo de limitación, en las Figuras de los dibujos adjuntos. La Figura 1 es una representación de un entorno de ejecución de multiprocesamiento heterogéneo;
La Figura 2 es una representación de un entorno de ejecución de multiprocesamiento heterogéneo;
La Figura 3 ilustra una implementación de ejemplo de un planificador heterogéneo;
La Figura 4 ilustra una realización del arranque del sistema y el descubrimiento de dispositivos de un sistema informático;
La Figura 5 ilustra un ejemplo de migración de hilos basándose en el mapeo de las fases del programa a tres tipos de elementos de procesamiento;
La Figura 6 es una implementación de ejemplo del flujo realizado por un planificador heterogéneo;
La Figura 7 ilustra un ejemplo de un método para la selección del destino de los hilos por un planificador heterogéneo; La Figura 8 ilustra un concepto de uso de mapeo en franjas para las ID lógicas;
La Figura 9 ilustra un ejemplo de uso de mapeo en franjas para las ID lógicas;
La Figura 10 ilustra un ejemplo de un grupo de núcleos;
La Figura 11 ilustra un ejemplo de un método de ejecución de hilos en un sistema que utiliza un mecanismo de cambio de traductor binario;
La Figura 12 ilustra un método ilustrativo de asignación de núcleos para código caliente a un acelerador;
La Figura 13 ilustra un método ilustrativo de asignación de núcleo potencial para una reactivación o escritura en un evento de registro base de directorio de página;
La Figura 14 ilustra un ejemplo de hilos de fase en serie;
La Figura 15 ilustra un método ilustrativo de asignación potencial de núcleos para la respuesta de un hilo a un evento de orden de inactividad;
La Figura 16 ilustra un método ilustrativo de asignación potencial de núcleos para un hilo en respuesta a un evento de cambio de fase;
La Figura 17 ilustra un ejemplo de código que delimita una región de aceleración;
La Figura 18 ilustra una realización de un método de ejecución que usa ABEGIN en un núcleo de procesador de hardware;
La Figura 19 ilustra una realización de un método de ejecución que usa AEND en un núcleo de procesador de hardware;
La Figura 20 ilustra un sistema que proporciona la equivalencia de ABEGIN/AEND usando la comparación de patrones; La Figura 21 ilustra una realización de un método de ejecución de un hilo de delineación no acelerada expuesto al reconocimiento de patrones;
La Figura 22 ilustra una realización de un método de ejecución de un hilo de delineación no acelerada expuesto al reconocimiento de patrones;
La Figura 23 ilustra diferentes tipos de dependencias de memoria, su semántica, requisitos de ordenación y casos de uso;
La Figura 24 ilustra un ejemplo de un bloque de datos de memoria apuntado por una instrucción ABEGIN;
La Figura 25 ilustra un ejemplo de memoria 2503 que está configurada para usar la semántica ABEGIN/AEND; La Figura 26 ilustra un ejemplo de un método de operación en un modo de ejecución diferente que usa ABEGIN/AEND; La Figura 27 ilustra un ejemplo de un método de operación en un modo de ejecución diferente que usa ABEGIN/AEND; La Figura 28 ilustra detalles adicionales de una implementación;
La Figura 29 ilustra una realización de un acelerador;
La Figura 30 ilustra sistemas informáticos que incluyen un acelerador y uno o más chips de procesador informático acoplados al procesador a través de un enlace multiprotocolo;
La Figura 31 ilustra los flujos de polarización del dispositivo de acuerdo con una realización;
La Figura 32 ilustra un proceso ilustrativo de acuerdo con una implementación;
La Figura 33 ilustra un proceso en el que los operandos se liberan de uno o más dispositivos de E/S;
La Figura 34 ilustra una implementación de uso de dos tipos diferentes de colas de trabajo;
La Figura 35 ilustra una implementación de un dispositivo acelerador de envío por flujo continuo de datos (DSA) que comprende múltiples colas de trabajo que reciben descriptores enviados a través de una interfaz de tejido de E/S; La Figura 36 ilustra dos colas de trabajo;
La Figura 37 ilustra otra configuración que usa motores y agrupaciones;
La Figura 38 ilustra una implementación de un descriptor;
La Figura 39 ilustra una implementación del registro de finalización;
La Figura 40 ilustra un descriptor de no-op ilustrativo y un registro de finalización de no-op;
La Figura 41 ilustra un descriptor de lote ilustrativo y un registro de finalización de no-op;
La Figura 42 ilustra un descriptor de drenaje ilustrativo y un registro de finalización de drenaje;
La Figura 43 ilustra un descriptor de movimiento de memoria ilustrativo y un registro de finalización de movimiento de memoria;
La Figura 44 ilustra un descriptor de llenado ilustrativo;
La Figura 45 ilustra un descriptor de comparación ilustrativo y un registro de finalización de comparación;
La Figura 46 ilustra un descriptor inmediato de comparación ilustrativo;
La Figura 47 ilustra un descriptor de crear registro de datos y registro de crear finalización de registro delta ilustrativos; La Figura 48 ilustra un formato del registro delta;
La Figura 49 ilustra un descriptor de registro delta de aplicación ilustrativo;
La Figura 50 muestra una implementación del uso de las operaciones de crear registro delta y aplicar registro delta; La Figura 51 ilustra una copia de memoria ilustrativa con un descriptor de reparto doble y una copia de memoria con un registro de finalización de reparto doble;
La Figura 52 ilustra un descriptor de generación de CRC ilustrativo y un registro de finalización de generación de CRC; La Figura 53 ilustra una copia ilustrativa con descriptor de generación de CRC;
La Figura 54 ilustra un descriptor de inserción DIF y un registro de finalización de inserción DIF ilustrativos;
La Figura 55 ilustra un descriptor de eliminación de DIF y un registro de finalización de eliminación de DIF ilustrativos; La Figura 56 ilustra un descriptor de actualización DIF y un registro de finalización de actualización DIF ilustrativos; La Figura 57 ilustra un descriptor de descarga de caché ilustrativo;
La Figura 58 ilustra un dato de almacén de cola de 64 bytes generado por ENQCMD;
La Figura 59 ilustra una realización de un método realizado por un procesador para procesar una instrucción MOVDIRI; La Figura 60 ilustra una realización de un método realizado por un procesador para procesar una instrucción MOVDIRI64B;
La Figura 61 ilustra una realización de un método realizado por un procesador para procesar una instrucción ENCQMD; La Figura 62 ilustra un formato para una instrucción ENQCMDS;
La Figura 63 ilustra una realización de un método realizado por un procesador para procesar una instrucción ENCQMDs;
La Figura 64 ilustra una realización de un método realizado por un procesador para procesar una instrucción UMONITOR;
La Figura 65 ilustra una realización de un método realizado por un procesador para procesar una instrucción UMWAIT; La Figura 66 ilustra una realización de un método realizado por un procesador para procesar una instrucción TPAUSE; La Figura 67 ilustra un ejemplo de ejecución que usa las instrucciones UMWAIT y UMONITOR;
La Figura 68 ilustra un ejemplo de ejecución que usa las instrucciones TPAUSE y UMONITOR;
La Figura 69 ilustra una implementación ilustrativa en la que un acelerador está acoplado comunicativamente a una pluralidad de núcleos a través de una interfaz coherente de caché;
La Figura 70 ilustra otra vista del acelerador y otros componentes descritos anteriormente, que incluyen una unidad de gestión de datos, una pluralidad de elementos de procesamiento y un almacenamiento rápido en el chip; La Figura 71 ilustra un conjunto ilustrativo de operaciones realizadas por los elementos de procesamiento;
La Figura 72A representa un ejemplo de una multiplicación entre una matriz dispersa A contra un vector x para producir un vector y;
La Figura 72B ilustra la representación CSR de la matriz A en la que cada valor se almacena como un par (valor, índice de fila);
La Figura 72C ilustra una representación CSC de la matriz A que usa un par (valor, índice de columna);
Las Figuras 73A, 73B y 73C ilustran el pseudocódigo de cada patrón de cálculo;
La Figura 74 ilustra el flujo de procesamiento para una implementación de la unidad de gestión de datos y los elementos de procesamiento;
La Figura 75a destacan las rutas (usando líneas discontinuas de puntos) de las operaciones spMspV_csc y scale_update;
La Figura 75b ilustra las rutas para una operación spMdV_csr;
Las Figuras 76a-b muestran un ejemplo de representación de un gráfico como una matriz de adyacencia;
La Figura 76c ilustra un programa de vértices;
La Figura 76d ilustra un código de programa ilustrativo para ejecutar un programa de vértices;
La Figura 76e muestra la formulación GSPMV;
La Figura 77 ilustra una estructura;
La Figura 78 ilustra que se proporcionan bloques lógicos personalizables dentro de cada PE;
La Figura 79 ilustra una operación de cada pieza aceleradora;
La Figura 80a resume los parámetros personalizables de una implementación de la plantilla;
La Figura 80b ilustra las consideraciones de ajuste;
La Figura 81 ilustra uno de los formatos de matriz dispersa más comunes;
La Figura 82 muestra las etapas implicadas en una implementación de la multiplicación de vectores densos-matrices dispersas usando el formato de datos CRS;
La Figura 83 ilustra una implementación del acelerador que incluye una pastilla lógica aceleradora y una o más pilas de DRAM;
Las Figuras 84A-B ilustran una implementación del chip lógico acelerador, orientado desde una perspectiva superior a través de la pila de pastillas DRAM;
La Figura 85 proporciona una visión general de alto nivel de un DPE;
La Figura 86 ilustra una implementación de un esquema de bloqueo;
La Figura 87 muestra un descriptor de bloque;
La Figura 88 ilustra una matriz de dos filas que se ajusta dentro de las memorias intermedias de un motor de producto escalar sencillo;
La Figura 89 ilustra una implementación del hardware en un motor de producto escalar que usa este formato;
La Figura 90 ilustra el contenido de la unidad lógica de comparación que realiza la captura;
La Figura 91 ilustra detalles del diseño de un motor de producto escalar para soportar la multiplicación de matrices dispersas-vectores dispersos de acuerdo con una implementación;
La Figura 92 ilustra un ejemplo que usa valores específicos;
La Figura 93 ilustra cómo se combinan los motores de productos escalares dispersos-densos y dispersos-dispersos para obtener un motor de productos escalares que pueda manejar ambos tipos de cálculos;
La Figura 94a ilustra una implementación de reemplazo de zócalo con 12 pilas de aceleradores;
La Figura 94b ilustra una implementación de paquete multichip (MCP) con un procesador/conjunto de núcleos y 8 pilas;
La Figura 95 ilustra las pilas de aceleradores;
La Figura 96 muestra una disposición potencial de un acelerador destinado a situarse bajo una pila de DRAM WIO3 que incluye 64 motores de productos escalares, 8 cachés vectoriales y un controlador de memoria integrado;
La Figura 97 compara siete tecnologías DRAM;
Las Figuras 98a-b ilustran DRAM apiladas;
La Figura 99 ilustra el listado de la búsqueda de amplitud (BFS);
La Figura 100 muestra el formato de los descriptores usados para especificar funciones Lambda de acuerdo con una implementación;
La Figura 101 ilustra los seis bytes inferiores de la palabra de encabezado en una realización;
La Figura 102 ilustra qué memoria intermedia de valores matriciales, la memoria intermedia de índices matriciales y la memoria intermedia de valores vectoriales;
La Figura 103 ilustra los detalles de una implementación de la ruta de datos Lambda;
La Figura 104 ilustra una implementación de la codificación de instrucciones;
La Figura 105 ilustra codificaciones para un conjunto particular de instrucciones;
La Figura 106 ilustra codificaciones de predicados de comparación ilustrativos;
La Figura 107 ilustra una realización que usa la polarización;
Las Figuras 108A-B ilustran registros de espacio de E/S mapeados en memoria (MMIO) usados con implementaciones basadas en colas de trabajo;
La Figura 109 ilustra un ejemplo de multiplicación de matrices;
La Figura 110 ilustra una operación de instrucción octoMADD con la red de reducción del árbol binario;
La Figura 111 ilustra una realización de un método realizado por un procesador para procesar una de multiplicaciónadición;
La Figura 112 ilustra una realización de un método realizado por un procesador para procesar una de multiplicaciónadición;
Las Figuras 113A-C ilustran un hardware ilustrativo para realizar una instrucción MADD;
La Figura 114 ilustra un ejemplo de circuito planificador heterogéneo de hardware y sus interacciones con la memoria; La Figura 115 ilustra un ejemplo de un planificador heterogéneo de software;
La Figura 116 ilustra una realización de un método para el descubrimiento de dispositivos después del arranque del sistema;
Las Figuras 117(A)-(B) ilustran un ejemplo de movimiento para un hilo en memoria compartida;
La Figura 118 ilustra un método ilustrativo para el movimiento de hilos que puede realizarse por el planificador heterogéneo;
La Figura 119 es un diagrama de bloques de un procesador configurado para presentar un entorno de ejecución abstracto como se ha detallado anteriormente;
La Figura 120 es un diagrama de bloques simplificado que ilustra una configuración multichip ilustrativa;
La Figura 121 ilustra un diagrama de bloques que representa al menos una porción de un sistema que incluye una implementación ilustrativa de un enlace multichip (MCL);
La Figura 122 ilustra un diagrama de bloques de una PHY lógica de ejemplo de un MCL de ejemplo;
La Figura 123 ilustra un diagrama de bloques simplificado que ilustra otra representación de la lógica usada para implementar un MCL;
La Figura 124 ilustra un ejemplo de ejecución cuando no se soporta ABEGIN/AEND;
La Figura 125 es un diagrama de bloques de una arquitectura de registro de acuerdo con una realización de la invención;
La Figura 126A es un diagrama de bloques que ilustra tanto una canalización en orden ilustrativa como una canalización de cambio de nombre de registro, emisión/ejecución fuera de orden ilustrativa de acuerdo con realizaciones de la invención;
La Figura 126B es un diagrama de bloques que ilustra tanto una realización ilustrativa de un núcleo de arquitectura en orden como un núcleo de arquitectura de cambio de nombre de registro, emisión/ejecución fuera de orden ilustrativa que va a incluirse en un procesador de acuerdo con realizaciones de la invención;
Las Figuras 127A-B ilustran un diagrama de bloques de una arquitectura de núcleo en orden ilustrativa más específica, cuyo núcleo sería uno de varios bloques lógicos (incluyendo otros núcleos del mismo tipo y/o de diferentes tipos) en un chip;
La Figura 128 es un diagrama de bloques de un procesador que puede tener más de un núcleo, puede tener un controlador de memoria integrado y puede tener gráficos integrados de acuerdo con realizaciones de la invención; La Figura 129 muestra un diagrama de bloques de un sistema de acuerdo con una realización de la presente invención; La Figura 130 es un diagrama de bloques de un primer sistema ilustrativo más específico de acuerdo con una realización de la presente invención;
La Figura 131 es un diagrama de bloques de un segundo sistema ilustrativo más específico de acuerdo con una realización de la presente invención;
La Figura 132 es un diagrama de bloques de un SoC de acuerdo con una realización de la presente invención; y La Figura 133 es un diagrama de bloques que contrapone el uso de un convertidor de instrucciones de software para convertir instrucciones binarias en un conjunto de instrucciones de origen en instrucciones binarias en un conjunto de instrucciones de destino de acuerdo con realizaciones de la invención.
Descripción detallada
En la siguiente descripción detallada, se hace referencia a los dibujos adjuntos que forman parte de la misma, en donde los números similares designan partes similares en todo el documento, y en los que se muestran a modo de ilustración realizaciones que pueden ponerse en práctica. Debe apreciarse que pueden utilizarse otras realizaciones y pueden hacerse cambios estructurales o lógicos sin alejarse del alcance de la presente divulgación. Por lo tanto, la siguiente descripción detallada no ha de tomarse en un sentido limitante, y se define el alcance de las realizaciones por las reivindicaciones adjuntas y sus equivalentes.
Diversas operaciones pueden describirse como múltiples acciones u operaciones discretas por turnos, de la manera que sea más útil para comprender la materia objeto reivindicada. Sin embargo, el orden de la descripción no debe interpretarse como que estas operaciones dependen necesariamente del orden. En particular, estas operaciones pueden no realizarse en el orden de presentación. Las operaciones descritas pueden realizarse en un orden diferente al de la realización descrita. Se pueden realizar diversas operaciones adicionales y/o se pueden omitir las operaciones descritas en realizaciones adicionales.
Para los propósitos de la presente divulgación, la expresión "A y/o B" significa (A), (B), o (A y B). Para los propósitos de la presente divulgación, la expresión "A, B y/o C" significa (A), (B), (C), (A y B), (A y C), (B y C), o (A, B y c ). La descripción puede usar las expresiones "en una realización" o "en realizaciones", que cada una puede referirse a una o más de las mismas o diferentes realizaciones. Además, las expresiones "que comprende", "que incluye", "que tiene" y similares, como se usan con respecto a las realizaciones de la presente divulgación, son sinónimas.
Como se ha analizado en los antecedentes, puede ser un reto desplegar soluciones de aceleración y gestionar la complejidad de usar aceleradores de forma portátil, ya que existe un amplio espectro de unidades de stock y plataformas que implementan diferentes mezclas de aceleradores. Además, dada la multiplicidad de sistemas operativos (y versiones, parches, etc.), el despliegue de aceleradores a través del modelo de controlador de dispositivo tiene limitaciones, que incluyen los obstáculos para su adopción debido al esfuerzo de los desarrolladores, la no portabilidad y los estrictos requisitos de rendimiento del procesamiento de las grandes cantidades de datos. Los aceleradores típicamente son dispositivos de hardware (circuitos) que realizan funciones de forma más eficiente que el software que se ejecuta en un procesador de propósito general. Por ejemplo, los aceleradores de hardware pueden usarse para mejorar la ejecución de un algoritmo/tarea específicos (tal como la codificación o decodificación de vídeo, funciones de troceo específicas, etc.) o clases de algoritmos/tareas (tales como el aprendizaje automático, la manipulación de datos dispersos, la criptografía, los gráficos, la física, las expresiones regulares, el procesamiento de paquetes, la inteligencia artificial, el procesamiento digital de señales, etc.). Algunos ejemplos de aceleradores incluyen, pero sin limitación, las unidades de procesamiento gráfico ("GPU"), los aceleradores de matriz de puertas programables en campo ("FPGA") de función fija y los circuitos integrados específicos de la aplicación ("ASIC") de función fija. Obsérvese que un acelerador, en algunas implementaciones, puede ser una unidad de procesamiento central ("CPU") de propósito general si esa CPU es más eficiente que otros procesadores en el sistema.
El presupuesto de energía de un sistema dado (por ejemplo, un sistema en un chip ("SOC"), una unidad de stock de procesador, un bastidor, etc.) puede consumirse por elementos de procesamiento en solo una fracción del área de silicio disponible. Esto hace que sea ventajoso crear una diversidad de bloques de hardware especializados que reduzcan el consumo de energía para operaciones específicas, incluso si no todos los bloques de hardware pueden estar activos simultáneamente.
Se detallan realizaciones de sistemas, métodos y aparatos para seleccionar un elemento de procesamiento (por ejemplo, un núcleo o un acelerador) para procesar un hilo, interconectarse con el elemento de procesamiento, y/o gestionar el consumo de energía dentro de un entorno multiprocesador heterogéneo. Por ejemplo, en diversas realizaciones, los multiprocesadores heterogéneos están configurados (por ejemplo, por diseño o por software) para migrar dinámicamente un hilo entre diferentes tipos de elementos de procesamiento de los multiprocesadores heterogéneos basándose en las características de una carga de trabajo correspondiente del hilo y/o de los elementos de procesamiento, para proporcionar una interfaz programática a uno o más de los elementos de procesamiento, para traducir el código para su ejecución en un elemento de procesamiento particular, para seleccionar un protocolo de comunicación que va a usarse con el elemento de procesamiento seleccionado basándose en las características de la carga de trabajo y del elemento de procesamiento seleccionado, o combinaciones de los mismos.
En un primer aspecto, una interfaz de despacho de cargas de trabajo, es decir, un planificador heterogéneo, presenta un modelo de programación multiprocesador homogéneo a los programadores de sistemas. En particular, este aspecto puede permitir a los programadores desarrollar software dirigido a una arquitectura específica, o una abstracción equivalente, facilitando al mismo tiempo las mejoras continuas del hardware subyacente sin requerir los cambios correspondientes en el software desarrollado.
En un segundo aspecto, un enlace multiprotocolo permite a una primera entidad (tal como un planificador heterogéneo) comunicarse con una multitud de dispositivos usando un protocolo asociado a la comunicación. Esto reemplaza la necesidad de tener enlaces separados para la comunicación de los dispositivos. En particular, este enlace tiene tres o más protocolos multiplexados dinámicamente en él. Por ejemplo, el enlace común soporta protocolos que consisten en: 1) un protocolo de productor/consumidor, descubrimiento, configuración, interrupciones (PDCI) para permitir el descubrimiento de dispositivos, la configuración de dispositivos, la notificación de errores, las interrupciones, las transferencias de datos de estilo DMA y diversos servicios que pueden especificarse en una o más normas propietarias o industriales (tales como, por ejemplo, una especificación PCI Express o una alternativa equivalente); 2) un protocolo de coherencia de agentes de caché (CAC) para permitir que un dispositivo emita solicitudes de lectura y escritura coherentes a un elemento de procesamiento; y 3) un protocolo de acceso a la memoria (MA) para permitir que un elemento de procesamiento acceda a una memoria local de otro elemento de procesamiento.
En un tercer aspecto, la planificación, la migración o la emulación de un hilo, o de porciones del mismo, se realiza basándose en una fase del hilo. Por ejemplo, típicamente, se planifica o migra una fase paralela de datos del hilo a un núcleo SIMD; típicamente, se planifica o migra una fase paralela del hilo a uno o más núcleos escalares; típicamente, se planifica o migra una fase en serie a un núcleo fuera de orden. Cada uno de los tipos de núcleo minimiza la energía o la latencia, y ambos se tienen en cuenta para la planificación, la migración o la emulación del hilo. La emulación puede usarse si la planificación o la migración no son posibles o ventajosas.
En un cuarto aspecto, un hilo, o porciones del mismo, se descargan a un acelerador de forma oportunista. En particular, una instrucción de comienzo de acelerador (ABEGIN) y una instrucción de fin de acelerador (AEND) del hilo, o porciones de las mismas, instrucciones de fin de libro que pueden ser ejecutables en un acelerador. Si no hay un acelerador disponible, entonces las instrucciones entre ABEGIN y AEND se ejecutan de forma normal. Sin embargo, cuando un acelerador está disponible, y es deseable usar el acelerador (usar menos energía, por ejemplo), entonces las instrucciones entre las instrucciones ABEGIN y AEND se traducen para ejecutarse en ese acelerador y se planifican para su ejecución en ese acelerador. Como tal, el uso del acelerador es oportunista.
En un quinto aspecto, un hilo, o porciones del mismo, se analiza para la descarga (oportunista) a un acelerador sin el uso de ABEGIN o AEND. Se ejecuta una comparación de patrones de software, o hardware, o partes del mismo, contra el hilo, para el código que puede ser ejecutable en un acelerador. Si un acelerador no está disponible, o el hilo, o porciones del mismo, no se presta a la ejecución del acelerador, entonces las instrucciones del hilo se ejecutan de forma normal. Sin embargo, cuando hay un acelerador disponible, y es deseable usar el acelerador (usar menos energía, por ejemplo), entonces las instrucciones se traducen para ejecutarse en ese acelerador y se planifican para su ejecución en ese acelerador. Como tal, el uso del acelerador es oportunista.
En un sexto aspecto, se realiza una traducción de un fragmento de código (porción de un hilo) para ajustarse mejor a un elemento de procesamiento de destino seleccionado. Por ejemplo, el fragmento de código: 1) se traduce para utilizar un conjunto de instrucciones diferente, 2) se hace más paralelo, 3) se hace menos paralelo (serializa), 4) se hace paralelo en datos (por ejemplo, vectorizado), y/o 5) se hace menos paralelo en datos (por ejemplo, no vectorizado).
En un séptimo aspecto, una cola de trabajo (ya sea compartida o especializada) recibe descriptores que definen el alcance del trabajo que va a hacerse por un dispositivo. Las colas de trabajo especializadas almacenan descriptores para una sola aplicación, mientras que las colas de trabajo compartidas almacenan descriptores enviados por múltiples aplicaciones. Una interfaz/arbitraje de hardware envía descriptores desde las colas de trabajo a los motores de procesamiento del acelerador de acuerdo con una política de arbitraje especificada (por ejemplo, basándose en los requisitos de procesamiento de cada aplicación y en las políticas de QoS/equidad).
En un octavo aspecto, una mejora para la multiplicación de matrices densas permite la multiplicación de matrices bidimensionales con la ejecución de una sola instrucción. Una pluralidad de fuentes de datos empaquetados (SIMD, vector) se multiplican contra una única fuente de datos empaquetados. En algunos casos, se usa un árbol binario para las multiplicaciones.
La Figura 1 es una representación de un entorno de ejecución de multiprocesamiento heterogéneo. En este ejemplo, el planificador heterogéneo 101 recibe un fragmento de código (por ejemplo, una o más instrucciones asociadas a un hilo de software) de un primer tipo. El fragmento de código puede tener la forma de cualquier número de representaciones de código fuente, incluyendo, por ejemplo, código máquina, una representación intermedia, código de bytes, código basado en texto (por ejemplo, código ensamblador, código fuente de un lenguaje de alto nivel tal como C++), etc. El planificador heterogéneo 101 presenta un modelo de programación multiprocesador homogéneo (por ejemplo, de manera que todos los hilos aparecen como si se ejecutaran en un núcleo escalar a un usuario y/o sistema operativo y determina un tipo de carga de trabajo (fase de programa) para el fragmento de código recibido, selecciona un tipo de elemento de procesamiento (escalar, fuera de orden (OOO), instrucción única, datos múltiples (SIMD) o acelerador) correspondiente al tipo de carga de trabajo determinada para procesar la carga de trabajo (por ejemplo, escalar para código paralelo de hilos, OOO para código en serie, SIMD para paralelo de datos, y un acelerador para paralelo de datos), y planifica el fragmento de código para su procesamiento por el elemento de procesamiento correspondiente. En la implementación específica mostrada en la Figura 1, los tipos de elementos de procesamiento incluyen el núcleo o núcleos escalares 103 (tales como núcleos en orden), el núcleo o núcleos de una sola instrucción y múltiples datos (SIMD) 105 que operan con operandos de datos empaquetados en donde un registro tiene múltiples elementos de datos almacenados consecutivamente, el núcleo o núcleos de baja latencia y fuera de orden 107, y el acelerador o aceleradores 109. En algunas realizaciones, el núcleo o núcleos escalares 103, el núcleo o núcleos de una sola instrucción y múltiples datos (SIMD) 105, el núcleo o núcleos de baja latencia y fuera de orden 107 están en un procesador heterogéneo y el acelerador o aceleradores 109 son externos a este procesador heterogéneo. Sin embargo, debe observarse que se pueden utilizar diferentes disposiciones de los elementos de procesamiento. En algunas implementaciones, el planificador heterogéneo 101 traduce o interpreta el fragmento de código recibido o una porción del mismo a un formato correspondiente al tipo de elemento de procesamiento seleccionado.
Los elementos de procesamiento 103-109 pueden soportar diferentes arquitecturas de conjuntos de instrucciones (ISA). Por ejemplo, un núcleo fuera de orden puede soportar una primera ISA y un núcleo dentro de orden puede soportar una segunda ISA. Esta segunda ISA puede ser un conjunto (sub o súper) de la primera ISA, o ser diferente. Adicionalmente, los elementos de procesamiento pueden tener diferentes microarquitecturas. Por ejemplo, un primer núcleo fuera de orden soporta una primera microarquitectura y un núcleo dentro de orden una segunda microarquitectura diferente. Obsérvese que, incluso dentro de un mismo tipo de elemento de procesamiento, la ISA y la microarquitectura pueden ser diferentes. Por ejemplo, un primer núcleo fuera de orden puede soportar una primera microarquitectura y un segundo núcleo fuera de orden puede soportar una microarquitectura diferente. Las instrucciones son "nativas" de una ISA particular en que forman parte de esa ISA. Las instrucciones nativas se ejecutan en microarquitecturas particulares sin necesidad de cambios externos (por ejemplo, la traducción).
En algunas implementaciones, uno o más de los elementos de procesamiento están integrados en una sola pastilla, por ejemplo, tal como un sistema en chip (SoC). Tales implementaciones pueden beneficiarse, por ejemplo, de la mejora de la latencia de las comunicaciones, la fabricación/costes, la reducción del número de patillas, la miniaturización de la plataforma, etc. En otras implementaciones, los elementos de procesamiento se empaquetan juntos, logrando de esta manera uno o más de los beneficios del SoC mencionado anteriormente sin estar en una sola pastilla. Estas implementaciones pueden beneficiarse, además, por ejemplo, de diferentes tecnologías de proceso optimizadas por tipo de elemento de procesamiento, de un tamaño de pastilla más pequeño para aumentar el rendimiento, de la integración de bloques de propiedad intelectual propios, etc. En algunas limitaciones convencionales de los paquetes múltiples, puede ser un reto comunicarse con dispositivos dispares a medida que se van añadiendo. El enlace multiprotocolo analizado en el presente documento minimiza, o alivia, este reto al presentar a un usuario, sistema operativo ("SO"), etc. una interfaz común para diferentes tipos de dispositivos.
En algunas implementaciones, el planificador heterogéneo 101 se implementa en un software almacenado en un medio legible por ordenador (por ejemplo, la memoria) para su ejecución en un núcleo de procesador (tal como el núcleo o núcleos 107 de OOO). En estas implementaciones, el planificador heterogéneo 101 se denomina planificador heterogéneo de software. Este software puede implementar un traductor binario, un compilador justo a tiempo ("JIT"), un SO 117 para planificar la ejecución de hilos que incluyen fragmentos de código, un comparador de patrones, un componente de módulo en el mismo, o una combinación de los mismos.
En algunas implementaciones, el planificador heterogéneo 101 se implementa en hardware tal como circuitos y/o máquinas de estado finito ejecutadas por circuitos. En estas implementaciones, el planificador heterogéneo 101 se denomina planificador heterogéneo de hardware.
Desde un punto de vista programático (por ejemplo, el SO 117, la capa de emulación, el hipervisor, el monitor de seguridad, etc.), cada tipo de elemento de procesamiento 103-109 utiliza un espacio de direcciones de memoria compartida 115. En algunas implementaciones, el espacio de direcciones de memoria compartida 115 comprende opcionalmente dos tipos de memoria, la memoria 211 y la memoria 213, como se ilustra en la Figura 2. En tales implementaciones, los tipos de memoria pueden distinguirse de diversas maneras, que incluyen, pero sin limitación: diferencias en las ubicaciones de la memoria (por ejemplo, ubicadas en diferentes zócalos, etc.), diferencias en las normas de interfaz correspondientes (por ejemplo, DDR4, DDR5, etc.), diferencias en los requisitos de energía, y/o diferencias en las tecnologías de memoria subyacentes usadas (por ejemplo, memoria de alto ancho de banda (HBM), DRAM sincrónica, etc.).
El espacio de direcciones de memoria compartida 115 es accesible por cada tipo de elemento de procesamiento. Sin embargo, en algunas realizaciones, se pueden asignar preferentemente diferentes tipos de memoria a diferentes elementos de procesamiento, por ejemplo, basándose en las necesidades de la carga de trabajo. Por ejemplo, en algunas implementaciones, una interfaz de firmware de plataforma (por ejemplo, BIOS o UEFI) o un almacenamiento de memoria incluye un campo para indicar los tipos de recursos de memoria disponibles en la plataforma y/o una afinidad de elementos de procesamiento para ciertos rangos de direcciones o tipos de memoria.
El planificador heterogéneo 101 utiliza esta información cuando analiza un hilo para determinar dónde debe ejecutarse el hilo en un punto en el tiempo dado. Típicamente, el mecanismo de gestión de hilos mira la totalidad de la información disponible para tomar una decisión informada sobre cómo gestionar los hilos existentes. Esto puede manifestarse de múltiples maneras. Por ejemplo, un hilo que se ejecuta en un elemento de procesamiento particular que tiene una afinidad por un rango de direcciones que está físicamente más cerca del elemento de procesamiento puede recibir un tratamiento preferencial sobre un hilo que bajo circunstancias normales se ejecutaría en ese elemento de procesamiento.
Otro ejemplo es que un hilo que se beneficiaría de un tipo de memoria particular (por ejemplo, una versión más rápida de DRAM) puede tener sus datos físicamente movidos a ese tipo de memoria y las referencias de memoria en el código ajustadas para apuntar a esa porción del espacio de direcciones compartido. Por ejemplo, mientras un hilo en el núcleo SIMD 205 puede utilizar el segundo tipo de memoria 213, puede moverse de este uso cuando un acelerador 209 está activo y necesita ese tipo de memoria 213 (o al menos necesita la porción asignada al hilo del núcleo SIMD 205).
Un escenario ilustrativo es cuando una memoria está físicamente más cerca de un elemento de procesamiento que de otros. Un caso común es el de un acelerador conectado directamente a un tipo de memoria diferente al de los núcleos.
En estos ejemplos, típicamente es el SO el que inicia el movimiento de datos. Sin embargo, nada impide que un nivel inferior (como el planificador heterogéneo) realice esta función por sí mismo o con ayuda de otro componente (por ejemplo, el SO). El hecho de que los datos del elemento de procesamiento anterior se descarguen y la entrada de la tabla de páginas se invalide o no depende de la implementación y de la penalización por hacer el movimiento de datos. Si no es probable que los datos se utilicen inmediatamente, puede ser más factible simplemente copiar desde el almacenamiento en lugar de mover los datos de un tipo de memoria a otro.
Las Figuras 117(A)-(B) ilustran un ejemplo de movimiento para un hilo en memoria compartida. En este ejemplo, dos tipos de memoria comparten un espacio de direcciones y cada uno tiene su propio rango de direcciones dentro de ese espacio. En 117(A), la memoria compartida 11715 incluye un primer tipo de memoria 11701 y un segundo tipo de memoria 11707. El primer tipo de memoria 11701 tiene un primer rango de direcciones 11703 y dentro de ese rango hay direcciones especializadas al hilo 1 11705. El segundo tipo de memoria 11707 tiene un segundo rango de direcciones 11709.
En algún punto durante la ejecución del hilo 111705, un planificador heterogéneo toma la decisión de mover el hilo 1 11705 para que un segundo hilo 11711 use las direcciones del primer tipo de memoria 11701 previamente asignadas al hilo 111705. Esto se muestra en la Figura 117(B). En este ejemplo, el hilo 111705 se reasigna al segundo tipo de memoria 11707 y se le da un nuevo conjunto de direcciones para usar; sin embargo, esto no tiene por qué ser así. Obsérvese que las diferencias entre tipos de memoria pueden ser físicas o espaciales (por ejemplo, basándose la distancia a un PE).
La Figura 118 ilustra un método ilustrativo para el movimiento de hilos que puede realizarse por el planificador heterogéneo. En 11801, un primer hilo se dirige para ejecutarse en un primer elemento de procesamiento ("PE"), como un núcleo o acelerador, usando un primer tipo de memoria en un espacio de memoria compartida. Por ejemplo, en la Figura 117(A) este es el hilo 1.
En algún punto en el tiempo posterior, se recibe una solicitud para ejecutar un segundo hilo en 11803. Por ejemplo, una aplicación, un SO, etc., solicita que se ejecute un hilo de hardware.
En 11805 se determina que el segundo hilo debe ejecutarse en un segundo PE usando el primer tipo de memoria en el espacio de direcciones compartido. Por ejemplo, el segundo hilo debe ejecutarse en un acelerador que está directamente acoplado al primer tipo de memoria y esa ejecución (incluyendo la liberación de la memoria que el primer hilo está usando) es más eficiente que hacer que el segundo hilo use un segundo tipo de memoria.
En algunas realizaciones, los datos del primer hilo se mueven desde el primer tipo de memoria a un segundo tipo de memoria en 11807. Esto no necesariamente ocurre si es más eficiente simplemente detener la ejecución del primer hilo e iniciar otro hilo en su lugar.
Las entradas de la memoria intermedia de traducción adelantada (TLB) asociadas al primer hilo se invalidan en 11809. Además, en la mayoría de las realizaciones, se realiza una descarga de los datos.
En 11811, el segundo hilo se dirige al segundo PE y se le asigna un rango de direcciones en el primer tipo de memoria que fueron previamente asignadas al primer hilo.
La Figura 3 ilustra una implementación de ejemplo de un planificador heterogéneo 301. En algunos casos, el planificador 301 es parte de un sistema de tiempo de ejecución. Como se ilustra, el detector de fase de programa 313 recibe un fragmento de código, e identifica una o más características del fragmento de código para determinar si la fase de ejecución del programa correspondiente se caracteriza mejor como serie, paralelo de datos o paralelo de hilos. A continuación, se detallan ejemplos de cómo se determina esto. Como se detalla con respecto a la Figura 1, el fragmento de código puede estar en forma de cualquier número de representaciones de código fuente.
Para los fragmentos de código recurrentes, el comparador de patrones 311 identifica este código "caliente" y, en algunos casos, también identifica las características correspondientes que indican que la carga de trabajo asociada con el fragmento de código puede ser más adecuada para su procesamiento en un elemento de procesamiento diferente. Se exponen a continuación más detalles relacionados con el comparador de patrones 311 y su operación en el contexto de la Figura 20, por ejemplo.
Un selector 309 selecciona un elemento de procesamiento objetivo para ejecutar la representación nativa del fragmento de código recibido basándose, al menos en parte, en las características del elemento de procesamiento y en la información térmica y/o de energía proporcionada por el gestor de energía 307. La selección de un elemento de procesamiento objetivo puede ser tan simple como la selección del mejor ajuste para el fragmento de código (es decir, una coincidencia entre las características de la carga de trabajo y las capacidades del elemento de procesamiento), pero también puede tener en cuenta un nivel de consumo de energía actual del sistema (por ejemplo, según puede proporcionarse por el gestor de energía 307), la disponibilidad de un elemento de procesamiento, la cantidad de datos a mover de un tipo de memoria a otro (y la penalización asociada para hacerlo), etc. En algunas realizaciones, el selector 309 es una máquina de estado finito implementada en, o ejecutada por, circuitos de hardware.
En algunas realizaciones, el selector 309 también selecciona un protocolo de enlace correspondiente para comunicarse con el elemento de procesamiento objetivo. Por ejemplo, en algunas implementaciones, los elementos de procesamiento utilizan las correspondientes interfaces de enlace comunes capaces de multiplexar o encapsular dinámicamente una pluralidad de protocolos en un tejido de sistema o en interconexiones punto a punto. Por ejemplo, en ciertas implementaciones, los protocolos soportados incluyen: 1) un protocolo de productor/consumidor, descubrimiento, configuración, interrupciones (PDCI) para permitir el descubrimiento de dispositivos, la configuración de dispositivos, la notificación de errores, las interrupciones, las transferencias de datos de estilo DMA y diversos servicios que pueden especificarse en una o más normas propietarias o industriales (tales como, por ejemplo, una especificación PCI Express o una alternativa equivalente); 2) un protocolo de coherencia de agentes de caché (CAC) para permitir que un dispositivo emita solicitudes de lectura y escritura coherentes a un elemento de procesamiento; y 3) un protocolo de acceso a la memoria (MA) para permitir que un elemento de procesamiento acceda a una memoria local de otro elemento de procesamiento. El selector 309 elige entre estos protocolos basándose en el tipo de solicitud que se va a comunicar al elemento de procesamiento. Por ejemplo, una solicitud de productor/consumidor, de descubrimiento, de configuración o de interrupción usa el protocolo PDCI, una solicitud de coherencia de caché usa el protocolo CAC y una solicitud de acceso a la memoria local usa el protocolo MA.
En algunas implementaciones, un hilo incluye marcadores para indicar un tipo de fase y, como tal, el detector de fase no se utiliza. En algunas implementaciones, un hilo incluye pistas o solicitudes explícitas para un tipo de elemento de procesamiento, protocolo de enlace y/o tipo de memoria. En estas implementaciones, el selector 309 utiliza esta información en su proceso de selección. Por ejemplo, una elección del selector 309 puede anularse por un hilo y/o un usuario.
Dependiendo de la implementación, un planificador heterogéneo puede incluir uno o más convertidores para procesar los fragmentos de código recibidos y generar las codificaciones nativas correspondientes para los elementos de procesamiento objetivo. Por ejemplo, el planificador heterogéneo puede incluir un traductor para convertir código máquina de un primer tipo en código máquina de un segundo tipo y/o un compilador justo a tiempo para convertir una representación intermedia a un formato nativo del elemento de procesamiento objetivo. Como alternativa, o, además, el planificador heterogéneo puede incluir un comparador de patrones para identificar fragmentos de código recurrentes (es decir, código "caliente") y almacenar en caché una o más codificaciones nativas del fragmento de código o las microoperaciones correspondientes. Cada uno de estos componentes opcionales se ilustra en la Figura 3. En particular, el planificador heterogéneo 301 incluye el traductor 303 y el compilador justo a tiempo 305. Cuando el planificador heterogéneo 301 opera sobre código objeto o una representación intermedia, se invoca al compilador justo a tiempo 305 para convertir el fragmento de código recibido en un formato nativo para uno o más de los elementos de procesamiento objetivo 103, 105, 107, 109. Cuando el planificador heterogéneo 301 opera en código máquina (binario), el traductor binario 303 convierte el fragmento de código recibido en código máquina nativo de uno o más de los elementos de procesamiento objetivo (tal como, por ejemplo, cuando se traduce de un conjunto de instrucciones a otro). En realizaciones alternativas, el planificador heterogéneo 301 puede omitir uno o más de estos componentes.
Por ejemplo, en algunas realizaciones, no se incluye ningún traductor binario. Esto puede dar como resultado un aumento de la complejidad de la programación, ya que un programa tendrá que tener en cuenta los aceleradores, núcleos, etc. potencialmente disponibles, en lugar de hacer que el planificador se encargue de esto. Por ejemplo, un programa puede necesitar incluir el código de una rutina en diferentes formatos. Sin embargo, en algunas realizaciones, cuando no hay un traductor binario hay un compilador JIT que acepta el código a un nivel superior y el compilador JIT realiza la traducción necesaria. Cuando un comparador de patrones está presente, el código caliente puede seguir detectándose para encontrar el código que debe ejecutarse en un elemento de procesamiento particular.
Por ejemplo, en algunas realizaciones, no se incluye ningún compilador JIT. Esto también puede dar como resultado un aumento de la complejidad de la programación, ya que un programa tendrá que compilarse en primer lugar en código máquina para un ISA concreto en lugar de hacer que el planificador se encargue de esto. Sin embargo, en algunas realizaciones, cuando hay un traductor binario y no un compilador JIT, el planificador puede traducir entre las ISA como se detalla a continuación. Cuando un comparador de patrones está presente, el código caliente puede seguir detectándose para encontrar el código que debe ejecutarse en un elemento de procesamiento particular.
Por ejemplo, en algunas realizaciones, no se incluye un comparador de patrones. Esto también puede dar como resultado una disminución de la eficiencia, ya que el código que podría haberse movido es más probable que se quede en un núcleo menos eficiente para la tarea particular que se está ejecutando.
En algunas realizaciones, no hay traductor binario, compilador JIT o comparador de patrones. En estas realizaciones, en la asignación/migración de hilos/elementos de procesamiento solo se utiliza la detección de fases o las solicitudes explícitas para mover un hilo.
Refiriéndose de nuevo a las Figuras 1-3, el planificador heterogéneo 101 puede implementarse en hardware (por ejemplo, circuitos), software (por ejemplo, código de programa ejecutable), o cualquier combinación de los mismos. La Figura 114 ilustra un ejemplo de circuito planificador heterogéneo de hardware y sus interacciones con la memoria. El planificador heterogéneo puede realizarse de muchas maneras diferentes, incluyendo, pero sin limitación, como una máquina de estado basada en una matriz de puertas programable en campo (FPGA) o en un circuito integrado específico de la aplicación (ASIC), como un microcontrolador integrado acoplado a una memoria que tiene almacenado en la misma software para proporcionar la funcionalidad que se detalla en el presente documento, circuitos lógicos que comprenden otros subcomponentes (por ejemplo, circuitos de detección de riesgo de datos, etc.), y/o como software (por ejemplo, una máquina de estado) ejecutado por un núcleo fuera de orden, como software (por ejemplo, una máquina de estado) ejecutado por un núcleo escalar, como software (por ejemplo, una máquina de estado) ejecutado por un núcleo SIMd , o una combinación de los mismos. En el ejemplo ilustrado, el planificador heterogéneo es circuitos 11401 que incluyen uno o más componentes para realizar diversas funciones. En algunas realizaciones, este circuito 11401 es una parte de un núcleo de procesador 11419, sin embargo, puede ser una parte de un conjunto de chips.
Un rastreador de hilos/elementos de procesamiento (PE) 11403 mantiene el estado de cada hilo que se ejecuta en el sistema y de cada PE (por ejemplo, la disponibilidad del PE, su consumo de energía actual, etc.). Por ejemplo, el rastreador 11403 mantiene un estado de activo, en reposo o inactivo en una estructura de datos tal como una tabla.
En algunas realizaciones, un comparador de patrones 11405 identifica el código "caliente", el código de acelerador, y/o el código que solicita una asignación de PE. Más adelante se proporcionan más detalles sobre esta comparación.
La información de PE 11409 almacena información sobre qué PE (y su tipo) están en el sistema y podrían planificarse por un SO, etc.
Aunque lo anterior se detalla como que son componentes separados dentro de un circuito planificador heterogéneo 11401, los componentes pueden combinarse y/o moverse fuera del circuito planificador heterogéneo 11401.
La memoria 11413 acoplada al circuito planificador heterogéneo 11401 puede incluir software para ejecutar (por un núcleo y/o el circuito planificador heterogéneo 11401) que proporciona funcionalidad adicional. Por ejemplo, se puede utilizar un comparador de patrones de software 11417 que identifica el código "caliente", el código del acelerador y/o el código que solicita una asignación de PE. Por ejemplo, el comparador de patrones de software 11417 compara la secuencia de códigos con un conjunto predeterminado de patrones almacenados en la memoria. La memoria también puede almacenar un traductor para traducir el código de un conjunto de instrucciones a otro (tal como de un conjunto de instrucciones a instrucciones o primitivas basadas en el acelerador).
Estos componentes alimentan un selector 11411 que hace una selección de un PE para ejecutar un hilo, qué protocolo de enlace usar, qué migración debe ocurrir si hay un hilo ya ejecutándose en ese PE, etc. En algunas realizaciones, el selector 11411 es una máquina de estado finito implementada en, o ejecutada por, circuitos de hardware.
La memoria 11413 también puede incluir, por ejemplo, en algunas implementaciones, uno o más traductores 11415 (por ejemplo, binario, compilador JIT, etc.) que se almacenan en la memoria para traducir el código de hilo a un formato diferente para un PE seleccionado.
La Figura 115 ilustra un ejemplo de un planificador heterogéneo de software. El planificador heterogéneo de software puede realizarse de muchas maneras diferentes, incluyendo, pero sin limitación, como una máquina de estado basada en una matriz de puertas programable en campo (FPGA) o en un circuito integrado específico de la aplicación (ASIC), como un microcontrolador integrado acoplado a una memoria que tiene almacenado en la misma software para proporcionar la funcionalidad que se detalla en el presente documento, circuitos lógicos que comprenden otros subcomponentes (por ejemplo, circuitos de detección de riesgo de datos, etc.), y/o como software (por ejemplo, una máquina de estado) ejecutado por un núcleo fuera de orden, como software (por ejemplo, una máquina de estado) ejecutado por un núcleo escalar, como software (por ejemplo, una máquina de estado) ejecutado por un núcleo SIMD, o una combinación de los mismos. En el ejemplo ilustrado, el planificador heterogéneo de software se almacena en la memoria 11413. Como tal, la memoria 11413 acoplada a un núcleo de procesador 11419 incluye software a ejecutar (por un núcleo) para programar hilos. En algunas realizaciones, el planificador heterogéneo de software es parte de un SO.
Dependiendo de la implementación, un rastreador de hilos/elementos de procesamiento (PE) 11403 en un núcleo mantiene el estado de cada hilo que se ejecuta en el sistema y de cada PE (por ejemplo, la disponibilidad del PE, su consumo de energía actual, etc.), o esto se realiza en software usando el rastreador de hilos/PE 11521. Por ejemplo, el rastreador mantiene un estado de activo, en reposo o inactivo en una estructura de datos tal como una tabla.
En algunas realizaciones, un comparador de patrones 11405 identifica el código "caliente" y/o el código que solicita una asignación de PE. Más adelante se proporcionan más detalles sobre esta comparación.
La información de PE 11409 y/o 11509 almacena información sobre qué PE están en el sistema y podrían planificarse por un SO, etc.
Puede usarse un comparador de patrones de software 11417 que identifica código "caliente", código de acelerador, y/o código que solicita una asignación de PE.
El rastreador de hilos/PE, la información del elemento de procesamiento, y/o las comparaciones de patrones se alimentan a un selector 11411 que hace una selección de un PE para ejecutar un hilo, qué protocolo de enlace utilizar, qué migración debe ocurrir si hay un hilo ya ejecutándose en ese PE, etc. En algunas realizaciones, el selector 11411 es una máquina de estado finito implementada y ejecutada por el núcleo del procesador 11419.
La memoria 11413 también puede incluir, por ejemplo, en algunas implementaciones, uno o más traductores 11415 (por ejemplo, binario, compilador JIT, etc.) que se almacenan en la memoria para traducir el código de hilo a un formato diferente para un PE seleccionado.
En funcionamiento, un SO planifica y hace que los hilos se procesen utilizando un planificador heterogéneo (tal como, por ejemplo, los planificadores heterogéneos 101,301), que presenta una abstracción del entorno de ejecución.
La tabla a continuación resume características de abstracción potenciales (es decir, lo que ve un programa), la libertad de diseño y las optimizaciones arquitectónicas potenciales (es decir, lo que se oculta al programador), y los beneficios potenciales o razones para proporcionar la característica particular en una abstracción.
TABLA
Figure imgf000014_0001
En algunas implementaciones ilustrativas, el planificador heterogéneo, en combinación con otros recursos de hardware y software, presenta un modelo de programación completo que ejecuta todo y soporta todas las técnicas de programación (por ejemplo, compilador, asuntos intrínsecos, ensamblador, bibliotecas, JIT, descarga, dispositivo). Otras implementaciones de ejemplo presentan entornos de ejecución alternativos conformes a los proporcionados por otras empresas de desarrollo de procesadores, tales como ARM Holdings, Ltd., MIPS, IBM, o sus licenciatarios o adoptantes.
La Figura 119 es un diagrama de bloques de un procesador configurado para presentar un entorno de ejecución abstracto como se ha detallado anteriormente. En este ejemplo, el procesador 11901 incluye varios tipos de núcleos diferentes tal como aquellos detallados en la Figura 1. Cada núcleo SIMD 11903 (amplio) incluye circuitos de acumulación/adición de multiplicación fusionada (FMA) que soportan primitivas aritméticas densas), su propia caché (por ejemplo, L1 y L2), circuitos de ejecución de propósito especial y almacenamiento para los estados de los hilos.
Cada núcleo 11913 de latencia optimizada (OOO) incluye circuitos de acumulación/adición múltiple fusionada (FMA), su propia caché (por ejemplo, L1 y L2) y circuitos de ejecución fuera de orden.
Cada núcleo escalar 11905 incluye circuitos de acumulación/adición de multiplicación fusionada (FMA), su propia caché (por ejemplo, L1 y L2), ejecución de propósito especial y almacena estados de hilos. Típicamente, los núcleos escalares 11905 soportan suficientes hilos para cubrir la latencia de la memoria. En algunas implementaciones, el número de núcleos SIMD 11903 y núcleos de latencia optimizada 11913 es pequeño en comparación con el número de núcleos escalares 11905.
En algunas realizaciones, se incluyen uno o más aceleradores 11905. Estos aceleradores 11905 pueden ser de función fija o basados en FPGA. Como alternativa, o, además de estos aceleradores 11905, en algunas realizaciones, los aceleradores 11905 son externos al procesador.
El procesador 11901 también incluye la caché de último nivel (LLC) 11907 compartida por los núcleos y, potencialmente, cualquier acelerador que se encuentre en el procesador. En algunas realizaciones, la LLC 11907 incluye circuitos para atómicos rápidos.
Una o más interconexiones 11915 acoplan los núcleos y aceleradores entre sí y con las interfaces externas. Por ejemplo, en algunas realizaciones, una interconexión de malla acopla los diversos núcleos.
Un controlador de memoria 11909 acopla los núcleos y/o aceleradores a la memoria.
Una pluralidad de interfaces de entrada/salida (por ejemplo, PCIe, enlace común detallado más adelante) 11911 conectan el procesador 11901 a dispositivos externos tales como otros procesadores y aceleradores.
La Figura 4 ilustra una realización del arranque del sistema y el descubrimiento de dispositivos de un sistema informático. El planificador heterogéneo utiliza el conocimiento del sistema, que incluye, por ejemplo, qué núcleos están disponibles, la cantidad de memoria disponible, las ubicaciones de la memoria en relación con los núcleos, etc. En algunas realizaciones, este conocimiento se construye usando una interfaz de configuración y alimentación avanzada (ACPI).
En el 401, se arranca el sistema informático.
Se realiza una consulta de los ajustes de configuración en 403. Por ejemplo, en algunos sistemas basados en BIOS, cuando se arranca, el BIOS prueba el sistema y prepara el ordenador para su operación consultando su propio banco de memoria para los ajustes de las unidades y otras configuraciones.
Se realiza una búsqueda de los componentes enchufados en 405. Por ejemplo, el BIOS busca los componentes enchufables del ordenador y establece punteros (vectores de interrupción) en la memoria para acceder a esas rutinas. El BIOS acepta las solicitudes de los controladores de dispositivos, así como de los programas de aplicación para interactuar con el hardware y otros dispositivos periféricos.
En 407, se genera una estructura de datos de los componentes del sistema (por ejemplo, núcleos, memoria, etc.). Por ejemplo, el BIOS típicamente genera información de configuración de dispositivos de hardware y periféricos a partir de la cual el SO interactúa con los dispositivos conectados. Además, ACPI define una interfaz de hardware flexible y extensible para la placa de sistema, y permite a un ordenador encender y apagar sus periféricos para mejorar la gestión de la energía, especialmente en dispositivos portátiles tales como los ordenadores portátiles. La especificación ACPI incluye interfaces de hardware, interfaces de software (API) y estructuras de datos que, cuando se implementan, soportan la configuración y la gestión de la energía dirigidas por el SO. Los diseñadores de software pueden usar ACPI para integrar las características de gestión de energía en todo el sistema informático, incluyendo el hardware, el sistema operativo y el software de aplicación. Esta integración permite al SO determinar qué dispositivos están activos y manejar todos los recursos de gestión de la energía de los subsistemas y periféricos del ordenador.
En 409, el sistema operativo (SO) se carga y obtiene el control. Por ejemplo, una vez que el BIOS ha completado sus rutinas de arranque, pasa el control al SO. Cuando una BIOS ACPI pasa el control de un ordenador al SO, el BIOS exporta al SO una estructura de datos que contiene el espacio de nombres ACPI, que puede representarse gráficamente como un árbol. El espacio de nombres actúa como un directorio de dispositivos ACPI conectados al ordenador, e incluye objetos que definen o proporcionan además información de estado para cada dispositivo ACPI. Cada nodo del árbol está asociado a un dispositivo, mientras que los nodos, subnodos y hojas representan objetos que, cuando se evalúan por el SO, controlarán el dispositivo o devolverán información especificada al SO, como se define en la especificación ACPI. El SO o un controlador al que se accede por el SO, puede incluir un conjunto de funciones para enumerar y evaluar los objetos del espacio de nombres. Cuando el SO llama a una función para devolver el valor de un objeto en el espacio de nombres ACPI, se dice que el SO evalúa ese objeto.
En algunos casos, los dispositivos disponibles cambian. Por ejemplo, se añade un acelerador, una memoria, etc. En la Figura 116 se ilustra una realización de un método de descubrimiento de dispositivos después del arranque del sistema. Por ejemplo, las realizaciones de este método pueden usarse para descubrir un acelerador que se ha añadido a un sistema después del arranque. En 11601 se recibe una indicación de que un dispositivo conectado que se está encendiendo o reseteando. Por ejemplo, el dispositivo final se enchufa a una ranura PCIe, o se reinicia, por ejemplo, por un SO.
En 11603, se realiza el entrenamiento de enlace con el dispositivo conectado y se inicializa el dispositivo conectado. Por ejemplo, se realiza el entrenamiento del enlace PCIe para establecer los parámetros de configuración de enlace, tal como la anchura de enlace, las polaridades de los carriles y/o la tasa máxima de datos soportada. En algunas realizaciones, las capacidades del dispositivo conectado se almacenan (por ejemplo, en una tabla ACPI).
Cuando el dispositivo conectado completa la inicialización, se envía un mensaje de listo desde el dispositivo conectado al sistema en 11605.
En 11607, se establece un bit de estado de dispositivo conectado listo para indicar que el dispositivo está listo para la configuración.
El dispositivo inicializado y conectado se configura en 11609. En algunas realizaciones, el dispositivo y el SO acuerdan una dirección para el dispositivo (por ejemplo, una dirección de E/S mapeada en memoria (MMIO)). El dispositivo proporciona un descriptor de dispositivo que incluye uno o más de: un número de identificación de proveedor (ID), un ID de dispositivo, un número de modelo, un número de serie, características, requisitos de recursos, etc. El SO puede determinar parámetros adicionales de operación y configuración para el dispositivo basándose en los datos del descriptor y los recursos del sistema. El SO puede generar consultas de configuración. El dispositivo puede responder con descriptores de dispositivo. A continuación, el SO genera datos de configuración y envía estos datos al dispositivo (por ejemplo, a través del hardware de PCI). Esto puede incluir la configuración de los registros de dirección base para definir el espacio de direcciones asociado al dispositivo.
Después de conocer que se ha creado el sistema, el SO planifica y hace que los hilos se procesen utilizando un planificador heterogéneo (tal como, por ejemplo, los planificadores heterogéneos 101, 301). El planificador heterogéneo mapea a continuación fragmentos de código de cada hilo, de forma dinámica y transparente (por ejemplo, para un usuario y/o un SO), al tipo de elemento de procesamiento más adecuado, evitando de esta manera potencialmente la necesidad de crear hardware para las características de la arquitectura heredada y, potencialmente, la necesidad de exponer los detalles de la microarquitectura al programador del sistema o al SO.
En algunos ejemplos, el tipo de elemento de procesamiento más adecuado se determina basándose en las capacidades de los elementos de procesamiento y las características de ejecución del fragmento de código. En general, los programas y los hilos asociados pueden tener diferentes características de ejecución dependiendo de la carga de trabajo que se esté procesando en un punto en el tiempo dado. Las características de ejecución ilustrativas, o fases de ejecución, incluyen, por ejemplo, fases paralelas de datos, fases paralelas de hilos y fases en serie. La tabla a continuación identifica estas fases y resume sus características. La tabla también incluye cargas de trabajo/operaciones de ejemplo, hardware ilustrativo útil para procesar cada tipo de fase, y un objetivo típico de la fase y el hardware usado.
TABLA
Figure imgf000016_0001
En algunas implementaciones, un planificador heterogéneo está configurado para elegir entre la migración de hilos y la emulación. En las configuraciones en las que cada tipo de elemento de procesamiento puede procesar cualquier tipo de carga de trabajo (en ocasiones requiriendo la emulación para hacerlo), el elemento de procesamiento más adecuado se selecciona para cada fase del programa basándose en uno o más criterios, que incluyen, por ejemplo, los requisitos de latencia de la carga de trabajo, una mayor latencia de ejecución asociada a la emulación, las características de energía y térmicas de los elementos de procesamiento y las restricciones, etc. Como se detallará más adelante, la selección de un elemento de procesamiento adecuado, en algunas implementaciones, se consigue considerando el número de hilos de ejecución y detectando la presencia de instrucciones SIMD o código vectorizable en el fragmento de código.
Mover un hilo entre elementos de procesamiento no está libre de penalización. Por ejemplo, puede ser necesario mover los datos a una caché de nivel inferior desde una caché compartida y tanto el elemento de procesamiento original como el elemento de procesamiento receptor tendrán sus canalizaciones descargadas para acomodar el movimiento. En consecuencia, en algunas implementaciones, el planificador heterogéneo implementa la histéresis para evitar migraciones demasiado frecuentes (por ejemplo, estableciendo valores umbral para uno o más criterios mencionados anteriormente, o un subconjunto de los mismos). En algunas realizaciones, la histéresis se implementa limitando las migraciones de hilos para que no excedan una tasa predefinida (por ejemplo, una migración por milisegundo). Como tal, el ritmo de migración está limitado para evitar una sobrecarga excesiva debido a la generación de código, la sincronización y la migración de datos.
En algunas realizaciones, por ejemplo, cuando el planificador heterogéneo no elige la migración como el enfoque preferido para un hilo particular, el planificador heterogéneo emula la funcionalidad faltante para el hilo en el elemento de procesamiento asignado. Por ejemplo, en una realización en la que el número total de hilos disponibles para el sistema operativo se mantiene constante, el planificador heterogéneo puede emular los múltiples hilos cuando un número de hilos de hardware disponibles (por ejemplo, en un núcleo de múltiples hilos amplio y simultáneo) está sobre­ suscrito. En un núcleo escalar o de latencia, una o más instrucciones SIMD del hilo se convierten en instrucciones escalares, o en un núcleo SIMD se generan más hilos y/o se convierten las instrucciones para utilizar datos empaquetados.
La Figura 5 ilustra un ejemplo de migración de hilos basándose en el mapeo de las fases del programa a tres tipos de elementos de procesamiento. Como se ilustra, los tres tipos de elementos de procesamiento incluyen los optimizados para la latencia (por ejemplo, un núcleo fuera de orden, un acelerador, etc.), los escalares (que procesan un elemento de datos a la vez por instrucción) y los SIMD (que procesan una pluralidad de elementos de datos por instrucción). Típicamente, el planificador heterogéneo realiza este mapeo de forma transparente para el programador y el sistema operativo basándose en cada hilo o fragmento de código.
Una implementación usa un planificador heterogéneo para mapear cada fase de la carga de trabajo al tipo de elemento de procesamiento más adecuado. Idealmente, esto mitiga la necesidad de construir hardware para las características heredadas y evita exponer los detalles de la microarquitectura, ya que el planificador heterogéneo presenta un modelo de programación completo que soporta múltiples tipos de código, tal como código compilado (código máquina), intrínsecos (construcciones de lenguaje de programación que se mapeen directamente a las instrucciones del procesador o del acelerador), código ensamblador, bibliotecas, intermedios (basados en JIT), descarga (mover de un tipo de máquina a otro) y específicos de dispositivo.
En ciertas configuraciones, una elección por defecto para un elemento de procesamiento objetivo es un elemento de procesamiento optimizado para la latencia.
Refiriéndose de nuevo a la Figura 5, se procesa inicialmente una fase de ejecución en serie 501 para una carga de trabajo en uno o más elementos de procesamiento de latencia optimizada. Tras la detección de un cambio de fase (por ejemplo, de forma dinámica a medida que el código se vuelve más paralelo a los datos o antes de la ejecución, como se observa, por ejemplo, por el tipo de instrucciones que se encuentran en el código antes de, o durante, la ejecución), la carga de trabajo se migra a uno o más elementos de procesamiento SIMD para completar una fase de ejecución paralela de datos 503. Adicionalmente, las planificaciones de ejecución y/o las traducciones típicamente se almacenan en caché. Posteriormente, la carga de trabajo se migra de nuevo a uno o más elementos de procesamiento de latencia optimizada, o a un segundo conjunto de uno o más elementos de procesamiento de latencia optimizada, para completar la siguiente fase de ejecución en serie 505. A continuación, la carga de trabajo se migra a uno o más núcleos escalares para procesar una fase de ejecución paralela de hilos 507. A continuación, la carga de trabajo se migra de nuevo a uno o más elementos de procesamiento de latencia optimizada para completar la siguiente fase de ejecución en serie 509.
Aunque este ejemplo ilustrativo muestra un retorno a un núcleo de latencia optimizada, el planificador heterogéneo puede continuar la ejecución de cualquier fase de ejecución posterior en uno o más tipos de elementos de procesamiento correspondientes hasta que el hilo se termine. En algunas implementaciones, un elemento de procesamiento utiliza colas de trabajo para almacenar las tareas que deben completarse. Como tal, las tareas pueden no comenzar inmediatamente, sino que se ejecutan a medida que se produce su lugar en la cola.
La Figura 6 es un ejemplo de flujo de implementación realizado por un planificador heterogéneo, tal como el planificador heterogéneo 101, por ejemplo. Este flujo representa la selección de un elemento de procesamiento (por ejemplo, un núcleo). Como se ilustra, el planificador heterogéneo recibe un fragmento de código. En algunas realizaciones, se ha producido un evento que incluye, pero sin limitación: comando de reactivación del hilo; una escritura en un registro base del directorio de páginas; un comando de inactividad; un cambio de fase en el hilo; y una o más instrucciones que indican una reasignación deseada.
En 601, el planificador heterogéneo determina si hay paralelismo en el fragmento de código (por ejemplo, si el fragmento de código está en una fase en serie o en una fase en paralelo), por ejemplo, basándose en las dependencias de datos detectadas, los tipos de instrucciones, y/o las instrucciones de flujo de control. Por ejemplo, un hilo lleno de código SIMD se consideraría paralelo. Si el fragmento de código no es susceptible de ser procesado en paralelo, el planificador heterogéneo selecciona uno o más elementos de procesamiento sensibles a la latencia (por ejemplo, núcleos OOO) para procesar el fragmento de código en la fase de ejecución en serie 603. Típicamente, los núcleos OOO tienen especulación (profunda) y planificación dinámica y normalmente tienen un rendimiento por vatio inferior al de las alternativas más sencillas.
En algunas realizaciones, no se dispone de ningún elemento de procesamiento sensible a la latencia, ya que típicamente consumen más energía y espacio en la pastilla que los núcleos escalares. En estas realizaciones, solo se dispone de núcleos escalares, SIMD y aceleradores.
Para los fragmentos de código paralelo, fragmentos de código paralelizable, y/o fragmentos de código vectorizable, el planificador heterogéneo determina el tipo de paralelismo del código en 605. Para los fragmentos de código paralelo de hilos, el planificador heterogéneo selecciona un elemento de procesamiento paralelo de hilos (por ejemplo, núcleos escalares multiprocesadores) en 607. Los fragmentos de código paralelo de hilos incluyen secuencias de instrucciones independientes que pueden ejecutarse simultáneamente en núcleos escalares separados.
El código paralelo de datos se produce cuando cada elemento de procesamiento ejecuta la misma tarea en diferentes piezas de datos. El código paralelo de datos puede venir en diferentes disposiciones de datos: empaquetados y aleatorios. La disposición de los datos se determina en 609. Los datos aleatorios pueden ser asignados a los elementos de procesamiento SIMD, pero se requiere la utilización de instrucciones de recopilación 613 para extraer datos de ubicaciones de memoria dispares, una matriz de cálculo espacial 615 (mapeando un cálculo espacialmente en una matriz de pequeños elementos de procesamiento programables, por ejemplo, una matriz de FPGA), o una matriz de elementos de procesamiento escalar 617. Los datos empaquetados se asignan a elementos de procesamiento SIMD o a elementos de procesamiento que usan primitivas aritméticas densas en 611.
En algunas realizaciones, se realiza una traducción del fragmento de código para que se ajuste mejor al elemento de procesamiento objetivo seleccionado. Por ejemplo, el fragmento de código: 1) se traduce para utilizar un conjunto de instrucciones diferente, 2) se hace más paralelo, 3) se hace menos paralelo (serializa), 4) se hace paralelo en datos (por ejemplo, vectorizado), y/o 5) se hace menos paralelo en datos (por ejemplo, no vectorizado).
Después de que se selecciona un elemento de procesamiento, el fragmento de código se transmite a uno de los elementos de procesamiento determinados para su ejecución.
La Figura 7 ilustra un ejemplo de un método para la selección del destino de los hilos por un planificador heterogéneo. En algunas realizaciones, este método se realiza mediante un traductor binario. En 701, se recibe un hilo, o un fragmento de código del mismo, para que se evalúe. En algunas realizaciones, se ha producido un evento que incluye, pero sin limitación: comando de reactivación del hilo; una escritura en un registro base del directorio de páginas; un comando de inactividad; un cambio de fase en el hilo; y una o más instrucciones que indican una reasignación deseada.
En 703 se realiza una determinación de si el fragmento de código debe descargarse a un acelerador. Por ejemplo, es el fragmento de código el que se enviará a un acelerador. El planificador heterogéneo puede saber que esta es la acción correcta cuando el código incluye código que identifica el deseo de usar un acelerador. Este deseo puede ser un identificador que indica que una región de código puede ejecutarse en un acelerador o ejecutarse de forma nativa (por ejemplo, ABEGIN/AEND descritos en el presente documento) o un comando explícito para usar un acelerador particular.
En algunas realizaciones, se realiza una traducción del fragmento de código para que se ajuste mejor al elemento de procesamiento objetivo seleccionado en 705. Por ejemplo, el fragmento de código: 1) se traduce para utilizar un conjunto de instrucciones diferente, 2) se hace más paralelo, 3) se hace menos paralelo (serializa), 4) se hace paralelo en datos (por ejemplo, vectorizado), y/o 5) se hace menos paralelo en datos (por ejemplo, no vectorizado).
Típicamente, un hilo traducido se almacena en caché 707 para su uso posterior. En algunas realizaciones, el traductor binario almacena en caché el hilo traducido localmente de manera que esté disponible para el uso del traductor binario en el futuro. Por ejemplo, si el código se vuelve "caliente" (se ejecuta repetidamente), la caché proporciona un mecanismo para su uso futuro sin una penalización de traducción (aunque puede haber un coste de transmisión).
El hilo (traducido) se transmite (por ejemplo, descarga) al elemento de procesamiento objetivo en 709 para su procesamiento. En algunas realizaciones, el hilo traducido se almacena en memoria caché por el destinatario de tal manera que está disponible localmente para su uso futuro. De nuevo, si el receptor o el traductor binario determina que el código está "caliente", este almacenamiento en caché permitirá una ejecución más rápida con un menor uso de energía.
En 711, el planificador heterogéneo determina si hay paralelismo en el fragmento de código (por ejemplo, si el fragmento de código está en una fase en serie o en una fase en paralelo), por ejemplo, basándose en las dependencias de datos detectadas, los tipos de instrucciones, y/o las instrucciones de flujo de control. Por ejemplo, un hilo lleno de código SIMD se consideraría paralelo. Si el fragmento de código no es susceptible de ser procesado en paralelo, el planificador heterogéneo selecciona uno o más elementos de procesamiento sensibles a la latencia (por ejemplo, núcleos OOO) para procesar el fragmento de código en la fase de ejecución en serie 713. Típicamente, los núcleos OOO tienen especulación (profunda) y planificación dinámica y, por tanto, pueden tener un mejor rendimiento por vatio en comparación con las alternativas escalares.
En algunas realizaciones, no se dispone de ningún elemento de procesamiento sensible a la latencia, ya que típicamente consumen más energía y espacio en la pastilla que los núcleos escalares. En estas realizaciones, solo se dispone de núcleos escalares, SIMD y aceleradores.
Para los fragmentos de código paralelo, fragmentos de código paralelizable, y/o fragmentos de código vectorizable, el planificador heterogéneo determina el tipo de paralelismo del código en 715. Para los fragmentos de código paralelo de hilos, el planificador heterogéneo selecciona un elemento de procesamiento paralelo de hilos (por ejemplo, núcleos escalares multiprocesadores) en 717. Los fragmentos de código paralelo de hilos incluyen secuencias de instrucciones independientes que pueden ejecutarse simultáneamente en núcleos escalares separados.
El código paralelo de datos se produce cuando cada elemento de procesamiento ejecuta la misma tarea en diferentes piezas de datos. El código paralelo de datos puede venir en diferentes disposiciones de datos: empaquetados y aleatorios. La disposición de los datos se determina en 719. Los datos aleatorios pueden asignarse a los elementos de procesamiento SIMD, pero requiere la utilización de instrucciones de recopilación 723, una matriz de cálculo espacial 725, o una matriz de elementos de procesamiento escalar 727. Los datos empaquetados se asignan a elementos de procesamiento SIMD o a elementos de procesamiento que usan primitivas aritméticas densas en 721.
En algunas realizaciones, se realiza una traducción de un fragmento de código no descargado para que se ajuste mejor al elemento de procesamiento objetivo determinado. Por ejemplo, el fragmento de código: 1) se traduce para utilizar un conjunto de instrucciones diferente, 2) se hace más paralelo, 3) se hace menos paralelo (serializa), 4) se hace paralelo en datos (por ejemplo, vectorizado), y/o 5) se hace menos paralelo en datos (por ejemplo, no vectorizado).
Después de que se selecciona un elemento de procesamiento, el fragmento de código se transmite a uno de los elementos de procesamiento determinados para su ejecución.
Un SO observa un número total de hilos que están potencialmente disponibles, independientemente de los núcleos y aceleradores que estén accesibles. En la siguiente descripción, cada hilo se enumera por un identificador de hilo (ID) llamado LogicallD. En algunas implementaciones, el sistema operativo y/o el planificador heterogéneo utilizan ID lógicos para mapear un hilo a un tipo de elemento de procesamiento particular (por ejemplo, tipo de núcleo), ID de elemento de procesamiento, y un ID de hilo en ese elemento de procesamiento (por ejemplo, una tupla de tipo de núcleo, coreID, threadID). Por ejemplo, un núcleo escalar tiene un ID de núcleo y uno o más ID de hilo; un núcleo SIMD tiene un ID de núcleo y uno o más ID de hilo; un núcleo de OOO tiene un ID de núcleo y uno o más ID de hilo; y/o un acelerador tiene un ID de núcleo y uno o más ID de hilo.
La Figura 8 ilustra un concepto de uso de mapeo en franjas para las ID lógicas. El mapeo en franjas puede usarse por un planificador heterogéneo. En este ejemplo, hay 8 ID lógicas y tres tipos de núcleos, teniendo, cada uno, uno o más hilos. Típicamente, el mapeo de LogicallD a (corelD, threadID) se calcula a través de la división y el módulo y puede fijarse para preservar la afinidad de los hilos de software. El mapeo de LogicallD a (tipo de núcleo) se realiza de forma flexible por el planificador heterogéneo para acomodar futuros nuevos tipos de núcleo accesibles al SO.
La Figura 9 ilustra un ejemplo de uso de mapeo en franjas para las ID lógicas. En el ejemplo, los LogicallD 1,4 y 5 se mapean a un primer tipo de núcleo y todos los demás LogicallD se mapean a un segundo tipo de núcleo. El tercer tipo de núcleo no se utiliza.
En algunas implementaciones, se realizan agrupaciones de tipos de núcleo. Por ejemplo, una tupla de "grupo de núcleos" puede consistir en una tupla OOO y todas las tuplas de núcleos escalares, SIMD y aceleradores cuyos ID lógicos se mapean a la misma tupla OOO. La Figura 10 ilustra un ejemplo de un grupo de núcleos. Típicamente, la detección de fase en serie y la migración de hilo se realizan dentro del mismo grupo de núcleos.
La Figura 11 ilustra un ejemplo de un método de ejecución de hilos en un sistema que utiliza un mecanismo de cambio de traductor binario. En 1101, un hilo se ejecuta en un núcleo. El núcleo puede ser de cualquiera de los tipos detallados en el presente documento, incluyendo un acelerador.
En algún punto en el tiempo durante la ejecución del hilo, se produce un evento de reasignación de núcleo potencial en 1103. Los eventos de reasignación de núcleo ilustrativos incluyen, pero sin limitación: comando de reactivación de hilo; una escritura en un registro base del directorio de páginas; un comando de inactividad; un cambio de fase en el hilo; y una o más instrucciones que indican una reasignación deseada a un núcleo diferente.
En 1105, se maneja el evento y se determina si debe haber un cambio en la asignación del núcleo. A continuación, se detallan métodos ilustrativos relacionados con el manejo de una asignación de núcleo particular.
En algunas realizaciones, la (re)asignación de núcleos está sujeta a uno o más factores limitantes, tales como la limitación de la tasa de migración y la limitación del consumo de energía. La limitación de la tasa de migración se rastrea por tipo de núcleo, corelD y threadID. Una vez que se ha asignado un hilo a un objetivo (tipo de núcleo, corelD, threadID) se inicia un temporizador y se mantiene por el traductor binario. No se deben migrar otros hilos al mismo objetivo hasta que el temporizador haya expirado. Como tal, mientras que un hilo puede migrar fuera de su núcleo actual antes de que el temporizador expire, lo contrario no se cumple.
Como se ha detallado, es probable que la limitación del consumo de energía sea cada vez más importante a medida que se añadan más tipos de núcleos (incluyendo los aceleradores) a un sistema informático (ya sea dentro o fuera de la pastilla). En algunas realizaciones, se calcula la energía instantánea consumida por todos los hilos en ejecución en todos los núcleos. Cuando el consumo de energía calculado supera un umbral, los nuevos hilos solo se asignan a los núcleos de menor potencia, tales como los SIMD, los escalares y los núcleos aceleradores especializados, y uno o más hilos se migran forzosamente de un núcleo OOO a los núcleos de menor potencia. Obsérvese que, en algunas implementaciones, la limitación del consumo de energía tiene prioridad sobre la limitación de la tasa de migración.
La Figura 12 ilustra un método ilustrativo de asignación de núcleos para código caliente a un acelerador. En 1203, se determina que el código es "caliente". Una porción de código caliente puede referirse a una porción de código que es más adecuada para ejecutarse en un núcleo que en el otro, basándose en consideraciones tales como la potencia, el rendimiento, el calor, otra métrica o métricas conocidas del procesador, o una combinación de los mismos. Esta determinación puede realizarse usando cualquier número de técnicas. Por ejemplo, se puede utilizar un optimizador binario dinámico para monitorizar la ejecución del hilo. El código caliente puede detectarse basándose en los valores de los contadores que registran la frecuencia de ejecución dinámica del código estático durante la ejecución del programa, etc. En la realización en la que un núcleo es un núcleo OOO y otro núcleo es un núcleo de orden, entonces una porción caliente de código puede referirse a un punto caliente del código del programa que es más adecuado para ejecutarse en el núcleo en serie, que potencialmente tiene más recursos disponibles para la ejecución de una sección altamente recurrente. A menudo, una sección de código con un patrón de alta recurrencia puede optimizarse para ejecutarse más eficientemente en un núcleo en orden. Esencialmente, en este ejemplo, el código frío (de baja recurrencia) se distribuye a un núcleo nativo, OOO, mientras que el código caliente (de alta recurrencia) se distribuye a un núcleo en orden gestionado por software. Una porción de código caliente puede identificarse de forma estática, dinámica o una combinación de las mismas. En el primer caso, un compilador o usuario puede determinar que una sección del código del programa es código caliente. La lógica de decodificación en un núcleo, en una realización, está adaptada para decodificar una instrucción de identificador de código caliente del código de programa, que es para identificar la porción caliente del código de programa. La obtención o decodificación de una instrucción de este tipo puede desencadenar la traducción y/o ejecución de la sección de código caliente en el núcleo. En otro ejemplo, la ejecución del código es una ejecución perfilada, y basándose en las características del perfil -métricas de potencia y/o rendimiento asociadas a la ejecución- puede identificarse una región del código del programa como código caliente. De forma similar a la operación del hardware, el código de monitorización puede ejecutarse en un núcleo para realizar la monitorización/perfilado del código del programa que se está ejecutando en el otro núcleo. Obsérvese que dicho código de monitorización puede ser un código mantenido en estructuras de almacenamiento dentro de los núcleos o mantenido en un sistema que incluye el procesador. Por ejemplo, el código de monitorización puede ser microcódigo, u otro código, mantenido en estructuras de almacenamiento de un núcleo. Como otro ejemplo, es la identificación estática del código caliente la que se realiza como una pista. Pero la elaboración de perfiles dinámicos de la ejecución del código del programa puede ignorar la identificación estática de una región de código como caliente; este tipo de identificación estática a menudo se denomina como una pista del compilador o del usuario que la creación de perfiles dinámicos puede tener en cuenta para determinar qué núcleo es apropiado para la distribución del código. Además, como es la naturaleza de la elaboración de perfiles dinámicos, la identificación de una región de código como caliente no restringe que esa sección de código se identifique siempre como caliente. Después de la traducción y/u optimización, se ejecuta una versión traducida de la sección de código.
En 1203 se selecciona un acelerador apropiado. El traductor binario, un monitor de la máquina virtual o el sistema operativo hacen esta selección basándose en los aceleradores disponibles y el rendimiento deseado. En muchos casos, un acelerador es más apropiado para ejecutar código caliente con un mejor rendimiento por vatio que un núcleo más grande y general.
El código caliente se transmite al acelerador seleccionado en 1205. Esta transmisión utiliza un tipo de conexión apropiado como se detalla en el presente documento.
Finalmente, el código caliente se recibe por el acelerador seleccionado y se ejecuta en 1207. Mientras se ejecuta, el código caliente puede evaluarse para una asignación a un núcleo diferente.
La Figura 13 ilustra un método ilustrativo de asignación de núcleo potencial para una reactivación o escritura en un evento de registro base de directorio de página. Por ejemplo, esto ilustra la determinación de una fase de un fragmento de código. En 1301, se detecta un evento de reactivación o un evento de registro base de directorio de página (por ejemplo, cambio de tarea). Por ejemplo, se produce un evento de reactivación por una interrupción que se recibe por un hilo detenido o por una salida de estado de espera. Una escritura en un registro base del directorio de páginas puede indicar el inicio o la finalización de una fase en serie. Típicamente, esta detección se produce en el núcleo que ejecuta el traductor binario.
Un número de núcleos que comparten un mismo puntero de base de tabla de páginas como el hilo que se reactivó, o experimentó un cambio de tarea, se cuenta en 1303. En algunas implementaciones, se usa una tabla para mapear los logicalID a núcleos heterogéneos particulares. La tabla está indexada por logicalID. Cada entrada de la tabla contiene una bandera que indica si el logicalID está actualmente en ejecución o detenido, una bandera que indica si se prefieren los núcleos SIMD o escalares, la dirección base de la tabla de páginas (por ejemplo, CR3), un valor que indica el tipo de núcleo al que el logicalID está actualmente mapeado, y contadores para limitar la tasa de migración.
Los hilos que pertenecen al mismo proceso comparten el mismo espacio de direcciones, las tablas de páginas y el valor del registro base del directorio de páginas.
En 1305 se determina si el número de núcleos contados es mayor que 1. Este recuento determina si el hilo se encuentra en una fase serie o paralela. Cuando el recuento es 1, entonces el hilo que experimenta el evento está en una fase serie 1311. Como tal, un hilo de fase serie es un hilo que tiene un valor de registro base de directorio de página único entre todos los hilos en el mismo grupo de núcleos. La Figura 14 ilustra un ejemplo de hilos de fase en serie. Como se ilustra, un proceso tiene uno o más hilos y cada proceso tiene su propia dirección asignada.
Cuando el hilo que experimenta el evento no está asignado a un núcleo OOO, se migra a un núcleo OOO y se migra un hilo existente en el núcleo OOO a un núcleo SIMD o escalar en 1313 o 1315. Cuando el hilo que experimenta el evento se asigna a un núcleo OOO, se queda allí en la mayoría de las circunstancias.
Cuando el recuento es mayor que 1, entonces el hilo que experimenta el evento está en una fase paralela y se hace una determinación del tipo de fase paralela en 1309. Cuando el hilo que experimenta el evento está en una fase paralela de datos, si el hilo no está asignado a un núcleo SIMD, se asigna a un núcleo SIMD, de lo contrario permanece en el núcleo SIMD si ya está allí en 1313.
Cuando el hilo que experimenta el evento está en una fase paralela de datos, si el hilo no está asignado al núcleo SIMD, se asigna a un núcleo SIMD, de lo contrario permanece en el núcleo SIMD si ya está allí en 1313.
Cuando el hilo que experimenta el evento está en una fase de hilo paralelo, si el hilo no está asignado a un núcleo escalar se asigna a uno, de lo contrario permanece en el núcleo escalar si ya está allí en 1315.
Adicionalmente, en algunas implementaciones, se establece una bandera que indica que el hilo se está ejecutando para el logicalID del hilo.
La Figura 15 ilustra un método ilustrativo de asignación potencial de núcleos para la respuesta de un hilo a un evento de orden de inactividad. Por ejemplo, esto ilustra la determinación de una fase de un fragmento de código. En 1501, se detecta un evento de inactividad que afecta al hilo. Por ejemplo, se ha producido un comando de parada, entrada de espera y tiempo de espera o pausa. Típicamente, esta detección se produce en el núcleo que ejecuta el traductor binario.
En algunas realizaciones, una bandera que indica que el hilo se está ejecutando se borra para el logicalID del hilo en 1503.
Se cuenta el número de hilos de los núcleos que comparten el mismo puntero base de la tabla de páginas que el hilo en inactividad en 1505. En algunas implementaciones, se usa una tabla para mapear los logicalID a núcleos heterogéneos particulares. La tabla está indexada por logicalID. Cada entrada de la tabla contiene una bandera que indica si el logicalID está actualmente en ejecución o detenido, una bandera que indica si se prefieren los núcleos SIMD o escalares, la dirección base de la tabla de páginas (por ejemplo, CR3), un valor que indica el tipo de núcleo al que el logicalID está actualmente mapeado, y contadores para limitar la tasa de migración. Se anota un primer hilo de ejecución (con cualquier puntero de base de la tabla de páginas) del grupo.
En 1507 se determina si un núcleo OOO del sistema está en reposo. Un núcleo de OOO en reposo no tiene hilos del 50 que se estén ejecutando activamente.
Cuando el puntero base de la tabla de páginas se comparte por exactamente un hilo en el grupo de núcleos, entonces ese hilo que comparte se mueve de un núcleo SIMD o escalar al núcleo OOO en 1509. Cuando el puntero base de la tabla de páginas se comparte por más de un hilo, entonces el primer hilo en ejecución del grupo, que se anotó anteriormente, se migra de un núcleo SIMD o escalar al núcleo OOO en 1511 para hacer espacio para el hilo reactivado (que se ejecuta en el lugar del primer hilo en ejecución).
La Figura 16 ilustra un método ilustrativo de asignación potencial de núcleos para un hilo en respuesta a un evento de cambio de fase. Por ejemplo, esto ilustra la determinación de una fase de un fragmento de código. En 1601, se detecta un evento de cambio de fase potencial. Típicamente, esta detección se produce en el núcleo que ejecuta el traductor binario.
En 1603 se determina si el logicalID del hilo se ejecuta en un núcleo escalar y si hay instrucciones SIMD presentes.
51 no hay tales instrucciones SIMD, entonces el hilo continúa ejecutándose normalmente. Sin embargo, cuando hay instrucciones SIMD presentes en el hilo que se ejecuta en un núcleo escalar, entonces el hilo se migra a un núcleo SIMD en 1605.
En 1607 se determina si el logicalID del hilo se ejecuta en un núcleo SIMD y si no hay instrucciones SIMD presentes. Si hay instrucciones SIMD, entonces el hilo continúa ejecutándose normalmente. Sin embargo, cuando no hay instrucciones SIMD presentes en el hilo que se ejecuta en un núcleo SIMD, entonces el hilo se migra a un núcleo escalar en 1609.
Como se ha señalado a lo largo de esta descripción, los aceleradores accesibles desde un traductor binario pueden proporcionar una ejecución más eficiente (incluyendo una ejecución más eficiente de energía). Sin embargo, ser apto para programar para cada acelerador potencial disponible puede ser una tarea difícil, si no imposible.
Se detallan en el presente documento las realizaciones que usan instrucciones de delineación para marcar explícitamente el comienzo y el final de la ejecución basada en el acelerador potencial de una porción de un hilo. Cuando no hay acelerador disponible, el código entre las instrucciones de delineación se ejecuta como sin el uso de un acelerador. En algunas implementaciones, el código entre estas instrucciones puede relajar alguna semántica del núcleo en el que se ejecuta.
La Figura 17 ilustra un ejemplo de código que delimita una región de aceleración. La primera instrucción de esta región es una instrucción de inicio de aceleración (ABEGIN) 1701. En algunas realizaciones, la instrucción ABEGIN da permiso para entrar en un (sub-)modo de ejecución relajado con respecto a los núcleos no aceleradores. Por ejemplo, en algunas implementaciones, una instrucción ABEGIN permite al programador o al compilador indicar en campos de la instrucción qué características del submodo son diferentes de un modo convencional. Las características ilustrativas incluyen, pero sin limitación, una o más de: ignorar el código auto-modificable (SMC), debilitar las restricciones del modelo de consistencia de la memoria (por ejemplo, relajar los requisitos de ordenación de almacén), alterar la semántica de coma flotante, cambiar la monitorización del rendimiento (perfmon), alterar el uso de la bandera arquitectónica, etc. En algunas implementaciones, el SMC es una escritura en una ubicación de memoria en un segmento de código que está actualmente en caché en el procesador, lo que hace que la línea (o líneas) de caché asociada se invalide. Si la escritura afecta a una instrucción prefijada, la cola de prefijación se invalida. Esta última comprobación se basa en la dirección lineal de la instrucción. Una escritura o un sondeo de una instrucción en un segmento de código, donde la instrucción objetivo ya está decodificada y residente en la caché de seguimiento, invalida toda la caché de seguimiento. El SMC puede ignorarse al activar los circuitos de detección de SMC en una memoria intermedia de traducción anticipada. Por ejemplo, las restricciones del modelo de consistencia de memoria pueden alterarse cambiando una configuración en uno o más registros o tablas (tal como un registro de rango de tipo de memoria o una tabla de atributos de página). Por ejemplo, al cambiar la semántica de coma flotante, se altera cómo un circuito de ejecución de coma flotante realiza un cálculo de coma flotante a través del uso de uno o más registros de control (por ejemplo, el ajuste de un registro de palabra de control de la unidad de coma flotante (FPU)) que controlan el comportamiento de estos circuitos. La semántica de la coma flotante que puede cambiar incluye, pero sin limitación, el modo de redondeo, cómo se tratan las máscaras de excepción y las banderas de estado, la nivelación a cero, el establecimiento de denormales y el control de la precisión (por ejemplo, simple, doble y extendida). Además, en algunas realizaciones, la instrucción ABEGIN permite la preferencia explícita del tipo de acelerador, de manera que si un acelerador de un tipo preferido está disponible, se elegirá.
El código no acelerador 1703 sigue a la instrucción ABEGIN 1701. Este código es nativo del núcleo o núcleos del procesador del sistema. En el peor de los casos, si no hay acelerador disponible, o no se soporta ABEGIN, este código se ejecuta en el núcleo tal cual. Sin embargo, en algunas implementaciones, se usa el submodo para la ejecución.
Al tener una instrucción de finalización de aceleración (AEND) 1705 la ejecución se bloquea en el núcleo del procesador hasta que el acelerador parece haber completado su ejecución. Efectivamente, el uso de ABEGIN y AEND permite a un programador optar por aceptar o rechazar el uso de un acelerador y/o un modo de ejecución relajado.
La Figura 18 ilustra una realización de un método de ejecución que usa ABEGIN en un núcleo de procesador de hardware. En 1801, se obtiene una instrucción ABEGIN de un hilo. Como se ha señalado anteriormente, la instrucción ABEGIN típicamente incluye uno o más campos que se usan para definir un (sub)modo de ejecución diferente.
La instrucción ABEGIN obtenida se decodifica usando los circuitos de decodificación en 1803. En algunas realizaciones, la instrucción ABEGIN se decodifica en microoperaciones.
La instrucción ABEGIN decodificada se ejecuta por los circuitos de ejecución para introducir el hilo en un modo diferente (que puede definirse explícitamente por uno o más campos de la instrucción ABEGIN) para las instrucciones que siguen a la instrucción ABEGIN, pero que son anteriores a una instrucción AEND en 1805. Este modo diferente de ejecución puede ser en un acelerador, o en el núcleo existente, dependiendo de la disponibilidad y selección del acelerador. En algunas realizaciones, la selección del acelerador se realiza por un planificador heterogéneo.
Las instrucciones posteriores, que no son AEND, se ejecutan en el modo de ejecución diferente en 1807. Las instrucciones pueden traducirse en primer lugar a un conjunto de instrucciones diferente por un traductor binario cuando se usa un acelerador para su ejecución.
La Figura 19 ilustra una realización de un método de ejecución que usa AEND en un núcleo de procesador de hardware. En 1901, se obtiene una instrucción AEND.
La instrucción AEND obtenida se decodifica usando los circuitos de decodificación en 1903. En algunas realizaciones, se decodifica AEND en microoperaciones.
La instrucción AEND decodificada se ejecuta por los circuitos de ejecución para revertir el modo de ejecución diferente previamente establecido por una instrucción ABEGIN en 1905. Este modo diferente de ejecución puede ser en un acelerador, o en el núcleo existente, dependiendo de la disponibilidad y selección del acelerador.
Las instrucciones posteriores, que no son AEND, se ejecutan en el modo de ejecución original en 1807. Las instrucciones pueden traducirse en primer lugar a un conjunto de instrucciones diferente por un traductor binario cuando se usa un acelerador para su ejecución.
La Figura 124 ilustra un ejemplo de ejecución cuando no se soporta ABEGIN/AEND. En 12401, se obtiene una instrucción ABEGIN. En 12403 se determina que no se soporta ABEGIN. Por ejemplo, el CPUID indica que no hay soporte.
Cuando no hay soporte, típicamente se ejecuta una operación no (nop) en 12405 que no cambia el contexto asociado al hilo. Dado que no hay ningún cambio en el modo de ejecución, las instrucciones que siguen a un ABEGIN no soportado se ejecutan normalmente en el 12407.
En algunas realizaciones, se consigue un uso equivalente de ABEGIN/AEND usando al menos la comparación de patrones. Esta comparación de patrones puede basarse en el hardware, el software y/o ambos. La Figura 20 ilustra un sistema que proporciona la equivalencia de ABEGIN/AEND usando la comparación de patrones. El sistema ilustrado incluye un planificador 2015 (por ejemplo, un planificador heterogéneo como se ha detallado anteriormente) que incluye un traductor 2001 (por ejemplo, traductor binario, JIT, etc.) almacenado en la memoria 2005. Los circuitos de núcleo 2007 ejecutan el planificador 2015. El planificador 2015 recibe un hilo 2019 que puede o no tener instrucciones ABEGIN/AEND explícitas.
El planificador 2015 gestiona un comparador de patrones basado en software 2003, realiza trampas y cambios de contexto durante la descarga, gestiona un área de grabación del espacio de usuario (detallado más adelante), y genera o traduce al código de acelerador 2011. El comparador de patrones 2003 reconoce secuencias de código (predefinidas) almacenadas en memoria que se encuentran en el hilo 2019 recibido que pueden beneficiarse del uso del acelerador y/o de un estado de ejecución relajado, pero que no están delineadas usando ABEGIN/AEND. Típicamente, los patrones mismos se almacenan en el traductor 2001, pero, como mínimo, son accesibles al comparador de patrones 2003. Un selector 2019 funciona como se ha detallado anteriormente.
El planificador 2015 también puede proporcionar características de monitorización del rendimiento. Por ejemplo, si el código no tiene una coincidencia de patrón perfecta, el planificador 2015 reconoce que el código puede necesitar aún una relajación de los requisitos para ser más eficiente y ajusta un modo de operación asociado con el hilo en consecuencia. La relación de un modo de operación se ha detallado anteriormente.
El planificador 2015 también realiza una o más de: ciclar un núcleo en una región ABEGIN/AEND, ciclar un acelerador para que esté activo o parado, contar las invocaciones ABEGIN, retardar la cola de los aceleradores (manejo de la sincronización) y monitorización de las estadísticas de memoria/caché. En algunas realizaciones, el traductor binario 2001 incluye código específico del acelerador usado para interpretar el código de acelerador que puede ser útil para identificar los cuellos de botella. El acelerador ejecuta este código traducido.
En algunas realizaciones, los circuitos principales 2007 incluyen un comparador de patrones de hardware 2009 para reconocer secuencias de código (predefinidas) en el hilo recibido 2019 utilizando patrones almacenados 2017. Típicamente, este comparador de patrones 2009 es más ligero en comparación con el comparador de patrones de software 2003 y busca regiones sencillas de expresar (tales como rep mov). Las secuencias de código reconocidas pueden traducirse para su uso en el acelerador por el planificador 2015 y/o pueden dar como resultado una relajación del modo de operación para el hilo.
Acoplados al sistema hay uno o más aceleradores 2013 que reciben el código de acelerador 2011 para ejecutarlo.
La Figura 21 ilustra una realización de un método de ejecución de un hilo de delineación no acelerada expuesto al reconocimiento de patrones. Este método se realiza por un sistema que incluye al menos un tipo de comparador de patrones.
En algunas realizaciones, un hilo se ejecuta en 2101. Típicamente, este hilo se ejecuta en un núcleo no acelerador. Las instrucciones del hilo de ejecución se alimentan en un comparador de patrones. Sin embargo, las instrucciones del hilo pueden alimentarse en un comparador de patrones antes de cualquier ejecución.
En 2103, se reconoce (detecta) un patrón dentro del hilo. Por ejemplo, un comparador de patrones basado en software, o un circuito comparador de patrones de hardware, encuentra un patrón que normalmente está asociado con un acelerador disponible.
El patrón reconocido se traduce para un acelerador disponible en 2105. Por ejemplo, un traductor binario traduce el patrón a código de acelerador.
El código traducido se transfiere al acelerador disponible en 2107 para su ejecución.
La Figura 22 ilustra una realización de un método de ejecución de un hilo de delineación no acelerada expuesto al reconocimiento de patrones. Este método se realiza por un sistema que incluye al menos un tipo de comparador de patrones como en el sistema de la Figura 20.
En algunas realizaciones, un hilo se ejecuta en 2201. Típicamente, este hilo se ejecuta en un núcleo no acelerador. Las instrucciones del hilo de ejecución se alimentan en un comparador de patrones. Sin embargo, las instrucciones del hilo pueden alimentarse en un comparador de patrones antes de cualquier ejecución.
En 2203, se reconoce (detecta) un patrón dentro del hilo. Por ejemplo, un comparador de patrones basado en software, o un circuito comparador de patrones de hardware, encuentra un patrón que normalmente está asociado con un acelerador disponible.
El traductor binario ajusta el modo de operación asociado con el hilo para usar requisitos relajados basados en el patrón reconocido en 2205. Por ejemplo, un traductor binario utiliza los ajustes asociados al patrón reconocido.
Como se detalla, en algunas realizaciones, las regiones paralelas de código están delimitadas por las instrucciones ABEGIN y AEND. Dentro del bloque ABEGIN/AEND, se garantiza la independencia de ciertas operaciones de carga y almacén de memoria. Otras cargas y almacenes permiten dependencias potenciales. Esto permite a las implementaciones paralelizar un bloque con poca o ninguna comprobación de las dependencias de memoria. En todos los casos, se permite la ejecución en serie del bloque, ya que el caso en serie está incluido entre las posibles formas de ejecutar el bloque. El traductor binario realiza un análisis estático de dependencias para crear instancias de ejecución paralela, y mapea estas instancias al hardware. El análisis de dependencia estático puede paralelizar las iteraciones de un bucle externo, medio o interno. La segmentación depende de la implementación. Las implementaciones de ABEGIN/AEND extraen el paralelismo en los tamaños más adecuados para la implementación.
El bloque ABEGIN/AEND puede contener varios niveles de bucles anidados. Las implementaciones son libres de elegir la cantidad de ejecución paralela soportada, o de recurrir a la ejecución en serie. ABEGIN/AEND proporciona paralelismo en regiones mucho más grandes que las instrucciones SIMD. Para ciertos tipos de código, ABEGIN/AEND permite implementaciones de hardware más eficientes que los múltiples hilos.
A través del uso de ABEGIN/AEND, un programador y/o compilador puede recurrir a la ejecución convencional en serie por un núcleo de la CPU si no se cumplen los criterios de paralelización. Cuando se ejecuta en un núcleo de CPU convencional fuera de orden, ABEGIN/AEND reduce los requisitos de área y energía de la memoria intermedia de ordenación de memoria (MOB) como resultado de la ordenación relajada de la memoria.
Dentro de un bloque ABEGIN/AEND, el programador especifica las dependencias de memoria. La Figura 23 ilustra diferentes tipos de dependencias de memoria 2301, su semántica 2303, requisitos de ordenación 2305 y casos de uso 2307. Además, algunas semánticas se aplican a las instrucciones dentro del bloque ABEGIN/AEND dependiendo de la implementación. Por ejemplo, en algunas realizaciones, se permiten dependencias de registro, pero las modificaciones de los registros no persisten más allá de AEND. Adicionalmente, en algunas realizaciones, un bloque ABEGIN/AEND debe entrar en ABEGIN y salir en AEND (o entrar en un estado similar basándose en el reconocimiento de patrones) sin ramales de entrada/salida del bloque ABEGIN/AEND. Finalmente, normalmente, el flujo de instrucciones no puede modificarse.
En algunas implementaciones, una instrucción ABEGIN incluye un operando de origen que incluye un puntero a un bloque de datos de memoria. Este bloque de memoria de datos incluye muchas piezas de información utilizadas por el tiempo de ejecución y los circuitos centrales para procesar el código dentro de un bloque ABEGIN /AEND.
La Figura 24 ilustra un ejemplo de un bloque de datos de memoria apuntado por una instrucción ABEGIN. Como se ilustra, dependiendo de la implementación, el bloque de datos de memoria incluye los campos para un número de secuencia 2401, una clase de bloque 2403, un identificador de implementación 2405, el tamaño del área de estado de grabación 2407 y el tamaño del área de almacenamiento local 2409.
El número de secuencia 2401 indica hasta dónde ha llegado el cálculo (paralelo) del procesador antes de una interrupción. El software inicializa el número de secuencia 2401 a cero antes de la ejecución de ABEGIN. La ejecución de ABEGIN escribirá valores distintos de cero en el número de secuencia 2401 para rastrear el progreso de la ejecución. Tras la finalización, la ejecución de AEND escribirá cero para reinicializar el número de secuencia 2401 para su próximo uso.
El identificador de clase de bloque predefinido 2403 (es decir, GUID) especifica una clase de bloque predefinida ABEGIN/AEND. Por ejemplo, DMULADD y DGEMM pueden predefinirse como clases de bloque. Con una clase predefinida, el traductor binario no necesita analizar el binario para realizar el análisis de mapeo para hardware heterogéneo. En su lugar, el traductor (por ejemplo, el traductor binario) ejecuta las traducciones pregeneradas para esta clase ABEGIN/AEND simplemente tomando los valores de entrada. El código encerrado con ABEGIN/AEND sirve simplemente como código usado para ejecutar esta clase en un núcleo no especializado.
El campo ID de implementación 2405 indica el tipo de hardware de ejecución que se está usando. La ejecución de ABEGIN actualizará este campo 2405 para indicar el tipo de hardware heterogéneo que se está usando. Esto ayuda a una implementación a migrar el código ABEGIN/AEND a una máquina que tiene un tipo de hardware de aceleración diferente o que no tiene un acelerador en absoluto. Este campo permite una posible conversión del contexto grabado para que coincida con la implementación objetivo. O bien, se usa un emulador para ejecutar el código hasta que sale de AEND después de la migración cuando se interrumpe el código ABEGIN/AEND y se migra a una máquina que no tiene el mismo tipo de acelerador. Este campo 2405 también puede permitir al sistema reasignar dinámicamente el bloque ABEGIN/AEND a un hardware heterogéneo diferente dentro de la misma máquina, incluso cuando se interrumpe en medio de la ejecución del bloque ABEGIN/AEND.
El campo de área de grabación de estado 2407 indica el tamaño y el formato del área de grabación de estado, que son específicos de la implementación. Una implementación garantizará que la porción específica de la implementación del área de grabación de estado no excederá algún máximo especificado en el CPUID. Normalmente, la ejecución de una instrucción ABEGIN provoca una escritura en el área de grabación de estado de los registros de propósito general y de datos empaquetados que se modificarán dentro del bloque ABEGIN/AEND, las banderas asociadas y el estado adicional específico de la implementación. Para facilitar la ejecución en paralelo, se pueden escribir múltiples instancias de los registros.
El área de almacenamiento local 2409 se asigna como área de almacenamiento local. La cantidad de almacenamiento a reservar se especifica normalmente como un operando inmediato a ABEGIN. Tras la ejecución de una instrucción ABEGIN, se realiza una escritura en un registro particular (por ejemplo, R9) con la dirección del almacenamiento local 2409. Si hay un fallo, este registro se hace apuntar al número de secuencia.
Cada instancia de ejecución paralela recibe un área de almacenamiento local única 2409. La dirección será diferente para cada instancia de ejecución paralela. En la ejecución en serie, se asigna un área de almacenamiento. El área de almacenamiento local 2409 proporciona almacenamiento temporal más allá de los registros arquitectónicos de propósito general y de datos empaquetados. No se debe acceder al área de almacenamiento local 2409 fuera del bloque ABEGIN/AEND.
La Figura 25 ilustra un ejemplo de memoria 2503 que está configurada para usar la semántica ABEGIN/AEND. No se ilustra el hardware (tal como los diversos elementos de procesamiento descritos en el presente documento) que soportan ABEGIN/AEND y utilizan esta memoria 2503. Como se ha detallado, la memoria 2503 incluye un área de estado grabación 2507 que incluye una indicación de los registros a utilizar 2501, banderas 2505, e información específica de la implementación 2511. Además, el almacenamiento local 2509 por instancia de ejecución paralela se almacena en la memoria 2503.
La Figura 26 ilustra un ejemplo de un método de operación en un modo de ejecución diferente que usa ABEGIN/AEND. Típicamente, este método se realiza por una combinación de entidades como un traductor y circuitos de ejecución. En algunas realizaciones, el hilo se traduce antes de entrar en este modo.
En 2601, se entra en un modo de ejecución diferente, tal como, por ejemplo, un modo de ejecución relajado (usando un acelerador o no). Normalmente, se entra en este modo a partir de la ejecución de una instrucción ABEGIN; sin embargo, como se ha detallado anteriormente, también puede entrarse en este modo debido a una coincidencia de patrón. La entrada en este modo incluye un reseteo del número de secuencia.
En 2603 se realiza una escritura en el área de estado grabación. Por ejemplo, se escriben los registros de propósito general y de datos empaquetados que se modificarán, las banderas asociadas y la información adicional específica de la implementación. Esta área permite reiniciar la ejecución, o retroceder, si algo va mal en el bloque (por ejemplo, una interrupción).
Se reserva un área de almacenamiento local por instancia de ejecución paralela en 2605. El tamaño de esta área está dictado por el campo de área de grabación del estado detallado anteriormente.
Durante la ejecución del bloque, el progreso del bloque se rastrea en 2607. Por ejemplo, cuando una instrucción se ejecuta con éxito y se retira, el número de secuencia del bloque se actualiza.
En 2609 se determina si se ha alcanzado la instrucción AEND (por ejemplo, para determinar si el bloque se ha completado). Si no es así, el área de almacenamiento local se actualiza con los resultados intermedios en 2613. Si es posible, la ejecución se retoma a partir de estos resultados; sin embargo, en algunos casos, se produce un retroceso hasta antes de que ocurra ABEGIN/AEND en 2615. Por ejemplo, si se produce una excepción o una interrupción durante la ejecución del bloque ABEGIN/AEND, el puntero de instrucción apuntará a la instrucción ABEGIN, y el registro R9 apuntará al bloque de datos de memoria que se actualiza con los resultados intermedios. Tras la reanudación, se usará el estado grabación en el bloque de datos de la memoria para reanudar en el punto correcto. Adicionalmente, se produce un fallo de página si la porción inicial del bloque de datos de memoria, hasta e incluyendo el área de grabación de estado, no está presente o no es accesible. Para las cargas y almacenes en el área de almacenamiento local, los fallos de página se notifican de la manera habitual, es decir, en el primer acceso a la página no presente o no accesible. En algunos casos, se usará un elemento de procesamiento no acelerador en el reinicio.
Si el bloque se completó con éxito, a continuación los registros que se apartaron se restauran junto con las banderas en 2611. Sólo el estado de la memoria será diferente después del bloque.
La Figura 27 ilustra un ejemplo de un método de operación en un modo de ejecución diferente que usa ABEGIN/AEND. Típicamente, este método se realiza por una combinación de entidades como un traductor binario y circuitos de ejecución.
En 2701, se entra en un modo de ejecución diferente, tal como, por ejemplo, un modo de ejecución relajado (usando un acelerador o no). Normalmente, se entra en este modo a partir de la ejecución de una instrucción ABEGIN; sin embargo, como se ha detallado anteriormente, también puede entrarse en este modo debido a una coincidencia de patrón. La entrada en este modo incluye un reseteo del número de secuencia.
En 2703 se realiza una escritura en el área de estado grabación. Por ejemplo, se escriben los registros de propósito general y de datos empaquetados que se modificarán, las banderas asociadas y la información adicional específica de la implementación. Esta área permite reiniciar la ejecución, o retroceder, si algo va mal en el bloque (por ejemplo, una interrupción).
Se reserva un área de almacenamiento local por instancia de ejecución paralela en 2705. El tamaño de esta área está dictado por el campo de área de grabación del estado detallado anteriormente.
En 2706, el código dentro del bloque se traduce para su ejecución.
Durante la ejecución del bloque traducido, el progreso del bloque se rastrea en 2707. Por ejemplo, cuando una instrucción se ejecuta con éxito y se retira, el número de secuencia del bloque se actualiza.
En 2709 se determina si se ha alcanzado la instrucción AEND (por ejemplo, para determinar si el bloque se ha completado). Si no es así, el área de almacenamiento local se actualiza con los resultados intermedios en 2713. Si es posible, la ejecución se retoma a partir de estos resultados, sin embargo, en algunos casos se produce un retroceso a antes de que ocurra ABEGIN/AEND en 2715. Por ejemplo, si se produce una excepción o una interrupción durante la ejecución del bloque ABEGIN/AEND, el puntero de instrucción apuntará a la instrucción ABEGIN, y el registro R9 apuntará al bloque de datos de memoria que se actualiza con los resultados intermedios. Tras la reanudación, se usará el estado grabación en el bloque de datos de la memoria para reanudar en el punto correcto. Adicionalmente, se produce un fallo de página si la porción inicial del bloque de datos de memoria, hasta e incluyendo el área de grabación de estado, no está presente o no es accesible. Para las cargas y almacenes en el área de almacenamiento local, los fallos de página se notifican de la manera habitual, es decir, en el primer acceso a la página no presente o no accesible. En algunos casos, se usará un elemento de procesamiento no acelerador en el reinicio.
Si el bloque se completó con éxito, a continuación los registros que se apartaron se restauran junto con las banderas en 2711. Sólo el estado de la memoria será diferente después del bloque.
Como se ha señalado anteriormente, en algunas implementaciones, se usa un enlace común (llamado enlace común multiprotocolo (MCL)) para llegar a los dispositivos (tal como los elementos de procesamiento descritos en las Figuras 1 y 2). En algunas realizaciones, estos dispositivos se ven como dispositivos PCI Express (PCIe). Este enlace tiene tres o más protocolos multiplexados dinámicamente en él. Por ejemplo, el enlace común soporta protocolos que consisten en: 1) un protocolo de productor/consumidor, descubrimiento, configuración, interrupciones (PDCI) para permitir el descubrimiento de dispositivos, la configuración de dispositivos, la notificación de errores, las interrupciones, las transferencias de datos de estilo DMA y diversos servicios que pueden especificarse en una o más normas propietarias o industriales (tales como, por ejemplo, una especificación PCI Express o una alternativa equivalente); 2) un protocolo de coherencia de agentes de caché (CAC) para permitir que un dispositivo emita solicitudes de lectura y escritura coherentes a un elemento de procesamiento; y 3) un protocolo de acceso a la memoria (MA) para permitir que un elemento de procesamiento acceda a una memoria local de otro elemento de procesamiento. Aunque se proporcionan a continuación ejemplos específicos de estos protocolos (por ejemplo, Tejido de Sistema En Chipo de Intel (IOSF), Interconexión Dentro de Pastilla (IDI), Interconexión de Memoria Escalable 3+ (SMI3+)), los principios subyacentes de la invención no se limitan a ningún conjunto concreto de protocolos.
La Figura 120 es un diagrama de bloques simplificado 12000 que ilustra una configuración multichip ilustrativa 12005 que incluye dos o más chips, o pastillas, (por ejemplo, 12010, 12015) conectados comunicativamente mediante un enlace multichip (MCL) ilustrativo 12020. Aunque la Figura 120 ilustra un ejemplo de dos (o más) pastillas que se interconectan usando un ejemplo de ACM 12020, debe apreciarse que los principios y características descritos en el presente documento en relación con las implementaciones de un MCL pueden aplicarse a cualquier interconexión o enlace que conecte una pastilla (por ejemplo, 12010) y otros componentes, incluyendo la conexión de dos o más pastillas (por ejemplo, 12010, 12015), la conexión de una pastilla (o chip) a otro componente fuera de la pastilla, la conexión de una pastilla a otro dispositivo o pastilla fuera del paquete (por ejemplo, 12005), la conexión de la pastilla a un paquete BGA, la implementación de un parche en el intercalador (POINT), entre otros ejemplos potenciales.
En algunos casos, los componentes más grandes (por ejemplo, las pastillas 12010, 12015) pueden ser a su vez sistemas de CI, tales como sistemas en chip (SoC), chips multiprocesadores u otros componentes que incluyen múltiples componentes tales como núcleos, aceleradores, etc. (12025-12030 y 12040-12045) en el dispositivo, por ejemplo, en una sola pastilla (por ejemplo, 12010, 12015). El MCL 12020 proporciona flexibilidad para construir sistemas complejos y variados a partir de múltiples componentes y sistemas potencialmente discretos. Por ejemplo, cada una de las pastillas 12010, 12015 puede fabricarse o suministrarse de otra manera por dos entidades diferentes. Además, las pastillas y otros componentes pueden incluir a su vez tejidos de interconexión u otros tejidos de comunicación (por ejemplo, 12035, 12050) que proporcionan la infraestructura para la comunicación entre los componentes (por ejemplo, 12025-12030 y 12040-12045) dentro del dispositivo (por ejemplo, 12010, 12015 respectivamente). Los diversos componentes e interconexiones (por ejemplo, 12035, 12050) soportan o usan múltiples protocolos diferentes. Además, la comunicación entre pastillas (por ejemplo, 12010, 12015) puede incluir potencialmente transacciones entre los diversos componentes de las pastillas a través de múltiples protocolos diferentes.
Las realizaciones del enlace multichip (MCL) soportan múltiples opciones de paquetes, múltiples protocolos de E/S, así como características de fiabilidad, disponibilidad y capacidad de servicio (RAS). Además, la capa física (PHY) puede incluir una capa eléctrica física y una capa lógica y puede soportar longitudes de canal más largas, incluyendo longitudes de canal de hasta, y en algunos casos superando, aproximadamente 45 mm. En algunas implementaciones, un ejemplo de MCL puede operar a altas velocidades de datos, incluyendo velocidades de datos superiores a 8-10 Gb/s.
En un ejemplo de implementación de un MCL, una capa eléctrica PHY mejora las soluciones tradicionales de interconexión multicanal (por ejemplo, E/S de DRAM multicanal), ampliando la velocidad de datos y la configuración de los canales, por ejemplo, mediante un número de características que incluyen, por ejemplo, la terminación regulada del carril medio, la cancelación de la diafonía activa de baja potencia, la redundancia del circuito, la corrección del ciclo de trabajo por bit y la eliminación de la desviación, la codificación de la línea y la ecualización del transmisor, entre otros ejemplos potenciales.
En un ejemplo de implementación de un MCL, una capa lógica PHY se implementa de tal manera que ayuda aún más (por ejemplo, las características de la capa eléctrica) en la ampliación de la velocidad de datos y la configuración del canal, mientras que también permite la interconexión para enrutar múltiples protocolos a través de la capa eléctrica. Tales implementaciones proporcionan y definen una capa física común modular que es agnóstica al protocolo y está diseñada para trabajar con potencialmente cualquier protocolo de interconexión existente o futuro.
Volviendo a la Figura 121, se muestra un diagrama de bloques simplificado 12100 que representa al menos una parte de un sistema que incluye una implementación de ejemplo de un enlace multichip (MCL). Un MCL puede implementarse usando conexiones eléctricas físicas (por ejemplo, cables implementados como carriles) que conectan un primer dispositivo 12105 (por ejemplo, una primera pastilla que incluye uno o más subcomponentes) con un segundo dispositivo 12110 (por ejemplo, una segunda pastilla que incluye uno o más subcomponentes). En el ejemplo particular mostrado en la representación de alto nivel del diagrama 12100, todas las señales (en los canales 12115, 12120) pueden ser unidireccionales y se pueden proporcionar carriles para que las señales de datos tengan una transferencia de datos aguas arriba y aguas abajo. Mientras que el diagrama de bloques 12100 de la Figura 121, se refiere al primer componente 12105 como el componente aguas arriba y al segundo componente 12110 como los componentes aguas abajo, y los carriles físicos del MCL usados en el envío de datos como un canal aguas abajo 12115 y los carriles usados para la recepción de datos (desde el componente 12110) como un canal aguas arriba 12120, debe apreciarse que el MCL entre los dispositivos 12105, 12110 puede usarse por cada dispositivo tanto para enviar como para recibir datos entre los dispositivos.
En una implementación de ejemplo, un MCL puede proporcionar una capa física (PHY) que incluye la MCL PHY 12125a,b eléctrica (o, colectivamente, 12125) y la lógica ejecutable que implementa la PHY lógica de MCL 12130a,b (o, colectivamente, 12130). La PHY 12125, eléctrica o física, proporciona la conexión física a través de la cual se comunican los datos entre los dispositivos 12105, 12110. Los componentes de acondicionamiento de señales y la lógica pueden implementarse en conexión con la PHY física 12125 para establecer una alta velocidad de datos y capacidades de configuración de canales del enlace que, en algunas aplicaciones, implica conexiones físicas estrechamente agrupadas en longitudes de aproximadamente 45 mm o más. La PHY lógica 12130 incluye circuitos para facilitar la sincronización, la gestión del estado del enlace (por ejemplo, para las capas de enlace 12135a, 12135b) y la multiplexación de protocolos entre protocolos potencialmente múltiples y diferentes usados para las comunicaciones a través del MCL.
En una implementación de ejemplo, la PHY física 12125 incluye, para cada canal (por ejemplo, 12115, 12120) un conjunto de carriles de datos, sobre los cuales se envían datos en banda. En este ejemplo particular, se proporcionan 50 carriles de datos en cada uno de los canales aguas arriba y aguas abajo 12115, 12120, aunque se puede usar cualquier otro número de carriles según lo permitan las limitaciones de diseño y energía, las aplicaciones deseadas, las limitaciones del dispositivo, etc. Cada canal puede incluir además uno o más carriles especializados para una señal estroboscópica, o de reloj, para el canal, uno o más carriles especializados para una señal válida para el canal, uno o más carriles especializados para una señal de flujo, y uno o más carriles especializados para una gestión de máquina de estado de enlace o señal de banda secundaria. La PHY física puede incluir además un enlace de banda secundaria 12140, que, en algunos ejemplos, puede ser un enlace bidireccional de señal de control de frecuencia inferior usado para coordinar las transiciones de estado y otros atributos de los dispositivos de conexión de MCL 12105, 12110, entre otros ejemplos.
Como se ha señalado anteriormente, se soportan múltiples protocolos usando una implementación de MCL. De hecho, se pueden proporcionar múltiples capas de transacción independientes 12150a, 12150b en cada dispositivo 12105, 12110. Por ejemplo, cada dispositivo 12105, 12110 puede soportar y utilizar dos o más protocolos, tales como PCI, PCIe, CAC, entre otros. CAC es un protocolo coherente usado en la pastilla para comunicarse entre los núcleos, las cachés de último nivel (LLC), la memoria, los gráficos y los controladores de E/S. También se pueden soportar otros protocolos, incluyendo el protocolo Ethernet, los protocolos Infiniband y otros protocolos basados en el tejido PCIe. La combinación de la PHY lógica y la PHY física también puede usarse como interconexión entre pastillas para conectar una PHY SerDes (PCIe, Ethernet, Infiniband u otras SerDes de alta velocidad) en una pastilla con sus capas superiores implementadas en la otra pastilla, entre otros ejemplos.
La PHY lógica 12130 soporta la multiplexación entre estos múltiples protocolos en un MCL. Por ejemplo, el carril de flujo especializado puede usarse para afirmar una señal de flujo codificada que identifica qué protocolo debe aplicarse a los datos enviados sustancialmente de forma simultánea en los carriles de datos del canal. Además, la PHY lógica 12130 negocia los diversos tipos de transiciones de estado de enlace que los distintos protocolos pueden soportar o solicitar. En algunos casos, las señales LSM_SB enviadas a través del carril LSM_SB especializado del canal pueden usarse, junto con el enlace de banda secundaria 12140 para comunicar y negociar las transiciones de estado del enlace entre los dispositivos 12105, 12110. Además, el entrenamiento de enlaces, la detección de errores, la eliminación de la desviación, y otras funcionalidades de las interconexiones tradicionales pueden sustituirse o regirse, en parte, usando la PHY lógica 12130. Por ejemplo, las señales válidas enviadas a través de uno o más carriles de señales válidas especializados en cada canal pueden usarse para señalar la actividad del enlace, detectar la desviación, los errores del enlace y realizar otras características, entre otros ejemplos. En el ejemplo particular de la Figura 121, se proporcionan múltiples carriles válidos por canal. Por ejemplo, los carriles de datos dentro de un canal pueden juntarse o agruparse (física y/o lógicamente) y se puede proporcionar un carril válido para cada agrupación. Además, se pueden proporcionar múltiples carriles estroboscópicos, en algunos casos, para proporcionar una señal estroboscópica especializada para cada agrupación en una pluralidad de agrupaciones de carriles de datos en un canal, entre otros ejemplos.
Como se ha indicado anteriormente, la PHY lógica 12130 negocia y gestiona las señales de control de enlace enviadas entre los dispositivos conectados por el MCL. En algunas implementaciones, la PHY lógica 12130 incluye circuitos de generación de paquetes de capa de enlace (LLP) 12160 para enviar mensajes de control de capa de enlace a través del MCL (es decir, en banda). Tales mensajes pueden enviarse a través de los carriles de datos del canal, identificando el carril de flujo que los datos son mensajes de capa de enlace a capa de enlace, tal como los datos de control de la capa de enlace, entre otros ejemplos. Los mensajes de la capa de enlace activados usando el módulo LLP 12160 ayudan a la negociación y realización de la transición de estado de la capa de enlace, la gestión de la energía, el bucle de retorno, la desactivación, el recentrado, la aleatorización, entre otras características de la capa de enlace entre las capas de enlace 12135a, 12135b de los dispositivos 12105, 12110, respectivamente.
Volviendo a la Figura 122, se muestra un diagrama de bloques simplificado 12200 que ilustra un ejemplo de PHY lógica de un MCL de ejemplo. Una PHY física 12205 puede conectarse a una pastilla que incluye la PHY lógica 12210 y una lógica adicional que soporta una capa de enlace del MCL. En este ejemplo, la pastilla puede incluir además lógica para soportar múltiples protocolos diferentes en el MCL. Por ejemplo, en el ejemplo de la Figura 122, se proporciona la lógica PCIe 12215 así como la lógica CAC 12220, de tal manera que las pastillas pueden comunicarse usando PCIe o CAC sobre el mismo MCL que conecta los dos pastillas, entre potencialmente muchos otros ejemplos, incluyendo ejemplos en los que se soportan más de dos protocolos o protocolos diferentes a PCIe y CAC sobre el MCL. Los diversos protocolos soportados entre las pastillas pueden ofrecer niveles variables de servicio y características.
La PHY lógica 12210 puede incluir la lógica de gestión de la máquina de estado de enlace 12225 para negociar las transiciones de estado de enlace en relación con las solicitudes de la lógica de capa superior de la pastilla (por ejemplo, recibidas a través de PCIe o CAC). La PHY lógica 12210 puede incluir además una lógica de prueba y depuración de enlace (por ejemplo, 12230), en algunas implementaciones. Como se ha indicado anteriormente, un ejemplo de MCL puede soportar señales de control que se envían entre pastillas a través del MCL para facilitar las características de agnosticidad de protocolo, alto rendimiento y eficiencia energética (entre otras características de ejemplo) del MCL. Por ejemplo, la PHY lógica 12210 puede soportar la generación y el envío, así como la recepción y el procesamiento de señales válidas, señales de flujo y señales de banda secundaria LSM en relación con el envío y la recepción de datos a través de carriles de datos especializados, tal como se describe en los ejemplos anteriores.
En algunas implementaciones, la lógica de multiplexación (por ejemplo, 12235) y demultiplexación (por ejemplo, 12240) puede incluirse en, o ser accesible de otra manera, para la PHY lógica 12210. Por ejemplo, la lógica de multiplexación (por ejemplo, 12235) puede usarse para identificar los datos (por ejemplo, realizados como paquetes, mensajes, etc.) que deben enviarse al MCL. La lógica de multiplexación 12235 puede identificar el protocolo que rige los datos y generar una señal de flujo que está codificada para identificar el protocolo. Por ejemplo, en una implementación de ejemplo, la señal de flujo puede codificarse como un byte de dos símbolos hexadecimales (por ejemplo, CAC: FFh; PCIe: F0h; LLP: AAh; banda secundaria: 55h; etc.), y pueden enviarse durante la misma ventana (por ejemplo, una ventana de período de tiempo de bytes) de los datos regidos por el protocolo identificado. De manera similar, la lógica de demultiplexación 12240 puede emplearse para interpretar las señales de flujo entrantes para decodificar la señal de flujo e identificar el protocolo que debe aplicarse a los datos recibidos simultáneamente con la señal de flujo en los carriles de datos. La lógica de demultiplexación 12240 puede a continuación aplicar (o asegurar) el manejo de la capa de enlace específica del protocolo y hacer que los datos se manejen por la lógica del protocolo correspondiente (por ejemplo, la lógica PCIe 12215 o la lógica CAC 12220).
La PHY lógica 12210 puede incluir además la lógica de paquetes de capa de enlace 12250 que puede usarse para manejar diversas funciones de control de enlace, incluyendo tareas de gestión de energía, el bucle de retorno, la desactivación, el recentrado, la aleatorización, etc. La lógica LLP 12250 puede facilitar los mensajes de capa de enlace a capa de enlace a través de MCLP, entre otras funciones. Los datos correspondientes a la señalización LLP también pueden identificarse por una señal de flujo enviada en un carril de señal de flujo especializado que está codificado para identificar los datos de LLP de los carriles de datos. La lógica de multiplexación y demultiplexación (por ejemplo, 12235, 12240) también puede usarse para generar e interpretar las señales de flujo correspondientes al tráfico LLP, así como para hacer que tal tráfico se maneje por la lógica de pastilla apropiada (por ejemplo, la lógica LLP 12250). Asimismo, como algunas implementaciones de un MCLP pueden incluir una banda secundaria especializada (por ejemplo, la banda secundaria 12255 y la lógica de apoyo), tal como un canal de banda secundaria asíncrono y/o de frecuencia inferior, entre otros ejemplos.
La lógica de la PHY lógica 12210 puede incluir además una lógica de gestión de la máquina de estado de enlace que puede generar y recibir (y usar) mensajería de gestión de estado de enlace a través de un carril de banda secundaria LSM especializado. Por ejemplo, puede usarse un carril de banda secundaria de LSM para realizar la toma de contacto para avanzar en el estado de entrenamiento del enlace, salir de los estados de gestión de energía (por ejemplo, un estado L1), entre otros ejemplos potenciales. La señal de banda secundaria de LSM puede ser una señal asíncrona, en el sentido de que no está alineada con las señales de datos, válidas y de flujo del enlace, sino que corresponde a la señalización de las transiciones de estado y al alineamiento de la máquina de estado del enlace entre las dos pastillas o chips conectados por el enlace, entre otros ejemplos. Proporcionar un carril de banda secundaria LSM especializado puede permitir, en algunos ejemplos, que se eliminen los circuitos tradicionales de silenciamiento y de detección de recepción de un extremo frontal analógico (AFE), entre otros beneficios de ejemplo.
Volviendo a la Figura 123, se muestra un diagrama de bloques simplificado 12300 que ilustra otra representación de la lógica usada para implementar un MCL. Por ejemplo, se proporciona la PHY lógica 12210 con una interfaz PHY lógica definida (LPIF) 12305 a través de la cual cualquiera de una pluralidad de protocolos diferentes (por ejemplo, PCIe, CAC, PDCI, MA, etc.) 12315, 12320, 12325 y modos de señalización (por ejemplo, banda secundaria) pueden interactuar con la capa física de un MCL de ejemplo. En algunas implementaciones, la lógica de multiplexación y arbitraje 12330 también puede proporcionarse como una capa separada de la PHY lógica 12210. En un ejemplo, la LPIF 12305 puede proporcionarse como la interfaz en cualquier lado de esta capa MuxArb 1230. La PHY lógica 12210 puede interactuar con la PHY física (por ejemplo, el extremo frontal analógico (AFE) 12205 de la PHY MCL) a través de otra interfaz.
La LPIF puede abstraer la PHY (lógica y eléctrica/analógica) de las capas superiores (por ejemplo, 12315, 12320, 12325) de tal manera que se puede implementar una PHY completamente diferente bajo la LPIF transparente a las capas superiores. Esto puede ayudar a fomentar la modularidad y la reutilización en el diseño, ya que las capas superiores pueden permanecer intactas cuando se actualiza la PHY de la tecnología de señalización subyacente, entre otros ejemplos. Además, la LPIF puede definir una serie de señales que permiten la multiplexación/demultiplexación, la gestión de LSM, la detección y el manejo de errores y otras funcionalidades de la PHY lógica. Por ejemplo, la siguiente tabla resume al menos una porción de las señales que pueden definirse para una LPIF de ejemplo:
Figure imgf000030_0001
Como se indica en la tabla, en algunas implementaciones, se puede proporcionar un mecanismo de alineación a través de una toma de contacto AlignReq/AlignAck. Por ejemplo, cuando la capa física entra en recuperación, algunos protocolos pueden perder la alineación de tramas de los paquetes. La alineación de los paquetes puede corregirse, por ejemplo, para garantizar la identificación de la alineación de tramas correcta por la capa de enlace. La capa física puede afirmar una señal StallReq cuando entra en recuperación, de manera que la capa de enlace afirma una señal Stall cuando un nuevo paquete alineado está listo para transferirse. La lógica de la capa física puede muestrear tanto Stall como Valid para determinar si el paquete está alineado. Por ejemplo, la capa física puede continuar controlando trdy para drenar los paquetes de la capa de enlace hasta que se afirmen de manera muestreada Stall y Valid, entre otras implementaciones potenciales, incluyendo otras implementaciones alternativas que usan Valid para ayudar en la alineación de paquetes.
Se pueden definir diversas tolerancias de fallo para las señales en el MCL. Por ejemplo, se pueden definir tolerancias de fallo para señales válidas, de flujo, de banda secundaria LSM, de banda secundaria de baja frecuencia, de paquetes de capa de enlace y de otros tipos. La tolerancia a los fallos de los paquetes, mensajes y otros datos enviados a través de los carriles de datos especializados del MCL puede estar basada en el protocolo particular que rige los datos. En algunas implementaciones, se pueden proporcionar mecanismos de detección y manejo de errores, tales como la comprobación de redundancia cíclica (CRC), memorias intermedias de reintento, entre otros ejemplos potenciales. Como ejemplos, para los paquetes PCIe enviados a través del MCL, se puede utilizar una CRC de 32 bits para los paquetes de la capa de transacción de PCIe (TLP) (con entrega garantizada (por ejemplo, a través de un mecanismo de repetición)) y una CRC de 16 bits para los paquetes de la capa de enlace PCIe (que pueden estar diseñados para tener pérdidas (por ejemplo, cuando no se aplica la repetición)). Además, para los testigos de alineación de tramas PCIe, se puede definir una distancia de Hamming particular (por ejemplo, una distancia Hamming de cuatro (4)) para el identificador del testigo; también se puede utilizar la paridad y la CRC de 4 bits, entre otros ejemplos. Por otra parte, para los paquetes CAC, se puede utilizar una CRC de 16 bits.
En algunas implementaciones, se definen tolerancias de fallo para los paquetes de la capa de enlace (LLP) que utilizan una señal válida para pasar de bajo a alto (es decir, de 0 a 1) (por ejemplo, para ayudar a asegurar el bloqueo de bits y símbolos). Además, en un ejemplo, se puede definir un número particular de LLP consecutivos e idénticos para enviarse y se pueden esperar respuestas a cada solicitud, con el reintento del solicitante después de un tiempo de espera de la respuesta, entre otras características definidas que pueden usarse como base para determinar los fallos en los datos de LLP en el MCL. En otros ejemplos, se puede proporcionar tolerancia a los fallos para una señal válida, por ejemplo, mediante la extensión de la señal válida a través de una ventana de período de tiempo completo, o símbolo (por ejemplo, manteniendo la señal válida alta durante ocho Ul). Además, pueden evitarse los errores o fallos en las señales de flujo manteniendo una distancia Hamming para los valores de codificación de la señal de flujo, entre otros ejemplos.
Las implementaciones de una PHY lógica incluyen la detección de errores, la notificación de errores y la lógica de manejo de errores. En algunas implementaciones, una PHY lógica de un MCL de ejemplo puede incluir lógica para detectar errores de desalineación de tramas de la capa PHY (por ejemplo, en los carriles válido y de flujo), errores de banda secundaria (por ejemplo, relacionados con las transiciones de estado de la LSM), errores en los LLP (por ejemplo, que son críticos para las transiciones de estado de la LSM), entre otros ejemplos. Parte de la detección/resolución de errores puede ser delegada a la lógica de la capa superior, tal como la lógica PCIe adaptada para detectar errores específicos de PCIe, entre otros ejemplos.
En el caso de los errores de desalineación de tramas, en algunas implementaciones, se pueden proporcionar uno o más mecanismos a través de la lógica de manejo de errores. Los errores de desalineación de tramas pueden tratarse basándose en el protocolo implicado. Por ejemplo, en algunas implementaciones, las capas de enlace pueden ser informadas del error para activar un reintento. La desalineación de tramas también puede causar una realineación de la desalineación de tramas de la PHY lógica. Además, se puede realizar el recentrado de la PHY lógica y recuperar el bloqueo de símbolo/ventana, entre otras técnicas. El centrado, en algunos ejemplos, puede incluir que la PHY mueva la fase del reloj del receptor al punto óptimo para detectar los datos entrantes. "Óptimo", en este contexto, puede referirse a dónde tiene el mayor margen de ruido y fluctuación de reloj. El recentrado puede incluir funciones de centrado simplificadas, por ejemplo, realizadas cuando la PHY se reactiva de un estado de baja potencia, entre otros ejemplos.
Otros tipos de errores pueden implicar otras técnicas de manejo de errores. Por ejemplo, los errores detectados en una banda secundaria pueden captarse mediante un mecanismo de tiempo de espera de un estado correspondiente (por ejemplo, de una LSM). El error puede ser registrado y la máquina de estado de enlace puede entonces pasar a Reseteo. La LSM puede permanecer en Reseteo hasta que se reciba un comando de reinicio desde el software. En otro ejemplo, los errores de LLP, tal como un error de paquete de control de enlace, se pueden manejar con un mecanismo de tiempo de espera que puede reiniciar la secuencia de LLP si no se recibe un acuse de recibo de la secuencia de LLP.
En algunas realizaciones, cada uno de los protocolos anteriores es una variante de PCIe. Los dispositivos PCIe se comunican usando un espacio de direcciones común que está asociado al bus. Este espacio de direcciones es un espacio de direcciones del bus o un espacio de direcciones PCIe. En algunas realizaciones, los dispositivos PCIe usan direcciones en un espacio de direcciones interno que puede ser diferente del espacio de direcciones PCIe.
Las especificaciones PCIe definen un mecanismo por el cual un dispositivo PCIe puede exponer su memoria local (o parte de la misma) al bus y permitir así que la CPU u otros dispositivos conectados al bus accedan a su memoria directamente. Típicamente, a cada dispositivo PCIe se le asigna una región especializada en el espacio de direcciones PCIe que se denomina registro de direcciones base PCI (BAR). Además, las direcciones que el dispositivo expone se mapean a las direcciones respectivas en la BAR de PCI.
En algunas realizaciones, un dispositivo PCIe (por ejemplo, HCA) traduce entre sus direcciones internas y las direcciones del bus PCIe usando una unidad de mapeo de memoria de entrada/salida (IOMMU). En otras realizaciones, el dispositivo PCIe puede realizar la traducción y resolución de direcciones usando un servicio de traducción de direcciones PCI (ATS). En algunas realizaciones, las etiquetas, tales como las etiquetas de ID del espacio de direcciones del proceso (PASID), se usan para especificar las direcciones que deben traducirse como pertenecientes al espacio de direcciones virtual de un proceso específico.
La Figura 28 ilustra detalles adicionales de una implementación. Como en las implementaciones descritas anteriormente, esta implementación incluye un acelerador 2801 con una memoria de acelerador 2850 acoplada a través de un enlace multiprotocolo 2800 a un procesador anfitrión 2802 con una memoria de anfitrión 2860. Como se ha mencionado, la memoria del acelerador 2850 puede utilizar una tecnología de memoria diferente a la de la memoria de anfitrión 2860 (por ejemplo, la memoria del acelerador puede ser HBM o DRAM apilada mientras que la memoria de anfitrión puede ser SDRAM).
Los multiplexores 2811 y 2812 se muestran para resaltar el hecho de que el enlace multiprotocolo 2800 es un bus multiplexado dinámicamente que soporta el tráfico de los protocolos PCDI, CAC y MA (por ejemplo, SMI3+), cada uno de los cuales puede enrutarse a diferentes componentes funcionales dentro del acelerador 2801 y el procesador anfitrión 2802. A modo de ejemplo, y no de limitación, estos protocolos pueden incluir IOSF, IDI y SMI3+. En una implementación, la lógica PCIe 2820 del acelerador 2801 incluye una TLB local 2822 para el almacenamiento en caché de las traducciones de direcciones virtuales a físicas para su uso por uno o más núcleos del acelerador 2830 cuando se ejecutan comandos. Como se ha mencionado, el espacio de memoria virtual se distribuye entre la memoria del acelerador 2850 y la memoria del anfitrión 2860. De manera similar, la lógica PCIe en el procesador anfitrión 2802 incluye una unidad de gestión de memoria de E/S (IOMMU) 2810 para gestionar los accesos a la memoria de los dispositivos de E/S PCIe 2806 y, en una implementación, el acelerador 2801. Como se ilustra en la lógica PCIe 2820 en el acelerador y en la lógica PCIe 2808 en el procesador anfitrión se comunican usando el protocolo PCDI para realizar funciones tales como el descubrimiento de dispositivos, el acceso a registros, la configuración e inicialización de dispositivos, el procesamiento de interrupciones, las operaciones DMA y los servicios de traducción de direcciones (ATS). Como se ha mencionado, IOMMU 2810 en el procesador anfitrión 2802 puede operar como el punto central de control y coordinación para estas funciones.
En una implementación, el núcleo del acelerador 2830 incluye los motores (elementos) de procesamiento que realizan las funciones requeridas por el acelerador. Además, el núcleo del acelerador 2830 puede incluir una memoria caché del anfitrión 2834 para almacenar en memoria caché localmente páginas en la memoria del anfitrión 2860 y una memoria caché del acelerador 2832 para almacenar en caché páginas en la memoria del acelerador 2850. En una implementación, el núcleo del acelerador 2830 se comunica con la lógica de coherencia y caché 2807 del procesador anfitrión 2802 a través del protocolo CAC para garantizar que las líneas de caché compartidas entre el acelerador 2801 y el procesador anfitrión 2802 permanezcan coherentes.
La lógica de polarización/coherencia 2840 del acelerador 2801 implementa las diversas técnicas de polarización de dispositivo/anfitrión descritas en el presente documento (por ejemplo, a granularidad de nivel de página) para garantizar la coherencia de los datos, al tiempo que se reduce la comunicación innecesaria a través del enlace multiprotocolo 2800. Como se ilustra, la lógica de polarización/coherencia 2840 se comunica con la lógica de coherencia y caché 2807 del procesador anfitrión 2802 usando transacciones de memoria MA (por ejemplo, SMI3+). La lógica de coherencia y caché 2807 es responsable de mantener la coherencia de los datos almacenados en su LLC 2809, la memoria del anfitrión 2860, la memoria del acelerador 2850 y las cachés 2832, 2834, y cada una de las cachés individuales de los núcleos 2805.
En resumen, una implementación del acelerador 2801 aparece como un dispositivo PCIe para el software ejecutado en el procesador anfitrión 2802, accediéndose por el protocolo PDCI (que es efectivamente el protocolo PCIe reformateado para un bus multiplexado). El acelerador 2801 puede participar en la memoria virtual compartida usando una TLB del dispositivo acelerador y servicios de traducción de direcciones PCIe convencionales (ATS). El acelerador también puede tratarse como un agente de coherencia/memoria. Ciertas capacidades (por ejemplo, ENQCMD, MOVDIR descritas más adelante) están disponibles en PDCI (por ejemplo, para la presentación de trabajos) mientras que el acelerador puede utilizar CAC para almacenar en caché los datos del anfitrión en el acelerador y en ciertos flujos de transición de polarización. Los accesos a la memoria del acelerador desde el anfitrión (o los accesos a la polarización del anfitrión desde el acelerador) pueden utilizar el protocolo MA como se describe.
Como se ilustra en la Figura 29, en una implementación, un acelerador incluye registros de configuración PCI 2902 y registros MMIO 2906 que pueden programarse para proporcionar acceso a los recursos de extremo trasero del dispositivo 2905. En una implementación, las direcciones base para los registros MMIO 2906 se especifican mediante un conjunto de Registros de Dirección Base (BAR) 2901 en el espacio de configuración PCI. A diferencia de las implementaciones anteriores, una implementación del acelerador de flujo de envío continuo de datos (DSA) descrito en el presente documento no implementa múltiples canales o funciones PCI, por lo que solo hay una instancia de cada registro en un dispositivo. Sin embargo, puede haber más de un dispositivo DSA en una misma plataforma.
Una implementación puede proporcionar registros adicionales de rendimiento o depuración que no se describen en este punto. Cualquier registro de este tipo debe considerarse específico para la implementación.
Los accesos al espacio de configuración PCI se realizan como accesos alineados de 1, 2 o 4 bytes. Obsérvese la especificación básica de PCI Express para conocer las reglas de acceso a los registros no implementados y a los bits reservados en el espacio de configuración de PCI.
Los accesos del espacio MMIO a la región BAR0 (registros de capacidad, configuración y estado) se realizan como accesos alineados de 1, 2, 4 u 8 bytes. Los accesos de 8 bytes solo deben utilizarse para registros de 8 bytes. El software no debe leer o escribir registros no implementados. Los accesos del espacio MMIO a las regiones BAR 2 y BAR 4 deben realizarse como accesos de 64 bytes, usando las instrucciones ENQCMD, ENQCMDS o MOVDIR64B (descritas en detalle más adelante). Se debe utilizar ENQCMD o ENQCMDS para acceder a una cola de trabajo que está configurada como compartida (SWQ), y MOVDIR64B para acceder a una cola de trabajo que está configurada como especializada (DWQ).
Una implementación del espacio de configuración PCI de DSA implementa tres BAR de 64 bits 2901. El Registro de Control de Dispositivos (BAR0) es un BAR de 64 bits que contiene la dirección base física de los registros de control de dispositivos. Estos registros proporcionan información sobre las capacidades del dispositivo, los controles para configurar y activar el dispositivo, y el estado del dispositivo. El tamaño de la región BAR0 depende del tamaño del almacenamiento de mensajes de interrupción 2904. El tamaño es de 32 KB más el número de entradas de almacenamiento de mensajes de interrupción 2904 veces 16, redondeado a la siguiente potencia de 2. Por ejemplo, si el dispositivo soporta 1024 entradas de almacenamiento de mensajes de interrupción 2904, el almacenamiento de mensajes de interrupción es de 16 KB, y el tamaño de BAR0 es de 64 KB.
BAR2 es un BAR de 64 bits que contiene la dirección base física de los portales con privilegios y sin privilegios. Cada portal tiene un tamaño de 64 bytes y se encuentra en una página separada de 4 KB. Esto permite mapear los portales de forma independiente en diferentes espacios de direcciones usando las tablas de páginas de la CPU. Los portales se utilizan para enviar descriptores al dispositivo. Los portales con privilegios se usan por el software en modo de núcleo, y los portales sin privilegios se usan por el software en modo usuario. El número de portales sin privilegios es el mismo que el número de colas de trabajo soportadas. El número de portales con privilegios es el número de colas de trabajo (WQ) x (tamaño de la tabla MSI-X - 1). La dirección del portal usado para enviar un descriptor permite al dispositivo determinar en qué WQ colocar el descriptor, si el portal tiene privilegio o no, y qué entrada de la tabla MSI-X puede usarse para la interrupción de finalización. Por ejemplo, si el dispositivo soporta 8 WQ, la WQ para un determinado descriptor es (dirección de portal >> 12) & 0x7. Si la dirección del portal >> 15 es 0, el portal no tiene privilegio; de lo contrario tiene privilegio y el índice de la tabla MSI-X 2903 usado para la interrupción de finalización es la dirección del portal >> 15. Los bits 5:0 deben ser 0. Los bits 11:6 se ignoran; por lo que cualquier dirección de 64 bytes alineada en la página puede usarse con el mismo efecto.
Los envíos de descriptores que utilizan un portal sin privilegio están sujetos al umbral de ocupación de la WQ, tal y como se configura usando un registro de configuración de la cola de trabajo (WQCFG). Los envíos de descriptores a través de un portal con privilegio no están sujetos al umbral. Los envíos de descriptores a una SWQ deben realizarse usando ENQCMD o ENQCMDS. Cualquier otra operación de escritura en un portal SWQ se ignora. El envío de descriptores a una DWQ debe realizarse mediante una operación de escritura de 64 bytes. El software usa MOv D|R64B, para garantizar una escritura de 64 bytes no rota. Un ENQCMD o ENQCMDS a un portal de WQ desactivado o especializado devuelve reintento. Cualquier otra operación de escritura en un portal DWQ se ignora. Cualquier operación de lectura en el espacio de direcciones BAR2 devuelve todos los valores 1. Los descriptores en modo de núcleo deben enviarse usando portales con privilegio para poder recibir interrupciones de finalización. Si se envía un descriptor en modo de núcleo usando un portal sin privilegio, no se puede solicitar una interrupción de finalización. Los descriptores en modo usuario pueden enviarse usando un portal con privilegio o un portal sin privilegio.
El número de portales en la región BAR2 es el número de WQ soportadas por el dispositivo multiplicado por el tamaño de la tabla MSI-X 2903. El tamaño de la tabla MSI-X suele ser el número de WQ más 1. Así, por ejemplo, si el dispositivo soporta 8 WQ, el tamaño útil de BAR2 sería 8 x 9 x 4 KB = 288 KB. El tamaño total de BAR2 se redondearía a la siguiente potencia de dos, es decir, 512 KB.
BAR4 es una barra de 64 bits que contiene la dirección base física de los portales invitados. Cada portal invitado tiene un tamaño de 64 bytes y se encuentra en una página separada de 4 KB. Esto permite mapear los portales de forma independiente en diferentes espacios de direcciones usando las tablas de páginas extendidas de la CPU (EPT). Si el campo de soporte de almacenamiento de mensajes de interrupción en GENCAP es 0, este BAR no se implementa.
Los portales invitados pueden usarse por el software del modo de núcleo de invitado para enviar descriptores al dispositivo. El número de portales invitados es el número de entradas en el almacenamiento de mensajes de interrupción multiplicado por el número de WQ soportadas. La dirección del portal invitado usada para enviar un descriptor permite al dispositivo determinar la WQ para el descriptor y también la entrada de almacenamiento de mensajes de interrupción a utilizar para generar una interrupción de finalización para la finalización del descriptor (si es un descriptor en modo de núcleo, y si la bandera de solicitud de interrupción de finalización está activada en el descriptor). Por ejemplo, si el dispositivo soporta 8 WQ, la WQ para un determinado descriptor es (dirección de portal invitado >> 12) & 0x7, y el índice de entrada de la tabla de interrupciones usado para la interrupción de finalización es dirección de portal invitado >> 15.
En una implementación, MSI-X es la única capacidad de interrupción PCIe que proporciona DSA y DSA no implementa interrupciones PCI heredadas o MSI. Los detalles de esta estructura de registro se encuentran en la especificación PCI Express.
En una implementación, tres capacidades PCI Express controlan la traducción de direcciones. Sólo se pueden soportar ciertas combinaciones de valores para estas capacidades, como se muestra en la Tabla A. Los valores se comprueban en el momento en que el bit de activación del registro de control general (GENCTRL) se establece a 1.
TABLA A
Figure imgf000034_0001
Si alguna de estas capacidades es modificada por el software mientras el dispositivo está activado, el dispositivo puede detenerse y se informa de un error en el registro de errores del software.
En una implementación, el software configura la capacidad de PASID para controlar si el dispositivo utiliza PASID para realizar la traducción de direcciones. Si se desactiva PASID, solo se pueden utilizar las direcciones físicas. Si se activa PASID, se pueden utilizar direcciones virtuales o físicas, dependiendo de la configuración de IOMMU. Si PASID está activado, tanto los servicios de traducción de direcciones (ATS) como los servicios de solicitud de páginas (PRS) deben activarse.
En una implementación, el software configura la capacidad ATS para controlar si el dispositivo debe traducir las direcciones antes de realizar los accesos a la memoria. Si se activa la traducción de direcciones en la IOMMU 2810, el ATS debe estar activado en el dispositivo para obtener un rendimiento aceptable del sistema. Si la traducción de direcciones no está activada en la IOMMU 2810, el ATS debe estar desactivado. Si el ATS está desactivado, solo se pueden utilizar las direcciones físicas y todos los accesos a la memoria se realizan mediante accesos no traducidos. ATS debe estar activado si PASID está activado.
En una implementación, el software configura la capacidad de PRS para controlar si el dispositivo puede solicitar una página cuando falla una traducción de direcciones. El PRS debe estar activado si PASID está activado, y debe estar desactivado si PASID está desactivado.
Algunas implementaciones utilizan un espacio de memoria virtual que se comparte sin problemas entre uno o más núcleos de procesador, dispositivos aceleradores y/u otros tipos de dispositivos de procesamiento (por ejemplo, dispositivos de E/S). En particular, una implementación utiliza una arquitectura de memoria virtual compartida (SVM) en la que el mismo espacio de memoria virtual se comparte entre los núcleos, los dispositivos aceleradores y/u otros dispositivos de procesamiento. Además, algunas implementaciones incluyen formas heterogéneas de memoria física del sistema que se direccionan usando un espacio de memoria virtual común. Las formas heterogéneas de memoria física del sistema pueden usar diferentes interfaces físicas para conectarse con las arquitecturas DSA. Por ejemplo, un dispositivo acelerador puede estar directamente acoplado a la memoria local del acelerador, tal como una memoria de alto ancho de banda (HBM), y cada núcleo puede estar directamente acoplado a una memoria física del anfitrión, tal como una memoria de acceso aleatorio dinámica (DRAM). En este ejemplo, la memoria virtual compartida (SVM) se mapea a la memoria física combinada de la HBM y la DRAM para que el acelerador, los núcleos del procesador y/u otros dispositivos de procesamiento puedan acceder a la HBM y la DRAM usando un conjunto coherente de direcciones de memoria virtual.
Estos y otros aceleradores de características se describen en detalle a continuación. A modo de resumen, diferentes implementaciones pueden incluir una o más de las siguientes características de infraestructura:
Memoria Virtual Compartida (SVM): algunas implementaciones soportan SVM que permite a las aplicaciones de nivel de usuario enviar comandos a DSA directamente con direcciones virtuales en los descriptores. DSA puede soportar la traducción de direcciones virtuales a direcciones físicas usando una unidad de gestión de memoria de entrada/salida (IOMMU), que incluye el manejo de fallos de página. Los rangos de direcciones virtuales a los que hace referencia un descriptor pueden abarcar varias páginas repartidas entre varios tipos de memoria heterogéneos. Además, una implementación también soporta el uso de direcciones físicas, siempre que las memorias intermedias de datos sean contiguas en la memoria física.
Finalización parcial del descriptor: con el soporte de SVM, es posible que una operación encuentre un fallo de página durante la traducción de direcciones. En algunos casos, el dispositivo puede terminar el procesamiento del descriptor correspondiente en el punto en el que se encuentra el fallo y proporcionar un registro de finalización al software indicando la finalización parcial y la información sobre el fallo para permitir que el software tome medidas correctivas y vuelva a intentar la operación después de resolver el fallo.
Procesamiento por lotes: algunas implementaciones soportan el envío de descriptores en un "lote" Un descriptor de lote apunta a un conjunto de descriptores de trabajo virtualmente contiguos (es decir, descriptores que contienen operaciones de datos reales). Al procesar un descriptor de lote, DSA obtiene los descriptores de trabajo de la memoria especificada y los procesa.
Dispositivo sin estado: los descriptores en una implementación están diseñados de manera que toda la información necesaria para procesar el descriptor viene en la propia carga útil del descriptor. Esto permite que el dispositivo almacene poco estado específico del cliente, lo que mejora su escalabilidad. Una excepción es el mensaje de interrupción de finalización que, cuando se usa, se configura por el software de confianza.
Control de la asignación de la caché: permite a las aplicaciones especificar si se escribe en la caché o se omite la caché y se escribe directamente en la memoria. En una implementación, los registros de finalización se escriben siempre en la caché.
Soporte de colas de trabajo compartidas (SWQ): como se describe en detalle más adelante, algunas implementaciones soportan el envío de trabajo escalable a través de colas de trabajo compartidas (SWQ) usando las instrucciones comando en cola (ENQCMD) y comandos en cola (ENQCMDS). En esta implementación, la SWQ se comparte por múltiples aplicaciones.
Soporte de colas de trabajo especializadas (DWQ): en algunas implementaciones, hay soporte para el envío de trabajo de alto rendimiento a través de colas de trabajo especializadas (DWQ) usando la instrucción MOVDIR64B. En esta implementación, el DWQ está especializado a una aplicación particular.
Soporte de QoS: algunas implementaciones permiten especificar un nivel de calidad de servicio (QoS) para cada cola de trabajo (por ejemplo, mediante un controlador del núcleo). A continuación, puede asignar diferentes colas de trabajo a diferentes aplicaciones, permitiendo que el trabajo de las diferentes aplicaciones se envíe desde las colas de trabajo con diferentes prioridades. Las colas de trabajo pueden programarse para usar canales específicos para la QoS del tejido.
Mecanismos de coherencia de caché polarizados
Una implementación mejora el rendimiento de los aceleradores con memoria adjunta directamente, tal como la DRAM apilada o la HBM, y simplifica el desarrollo de aplicaciones que hacen uso de aceleradores con memoria adjunta directamente. Esta implementación permite mapear la memoria adjunta al acelerador como parte de la memoria del sistema, y acceder a ella usando la tecnología de memoria virtual compartida (SVM) (tal como la usada en las implementaciones actuales de IOMMU), pero sin sufrir los típicos inconvenientes de rendimiento asociados a la coherencia total de la caché del sistema.
La capacidad de acceder a la memoria adjunta al acelerador como parte de la memoria del sistema sin una ardua sobrecarga de coherencia de caché proporciona un entorno operativo beneficioso para la descarga del acelerador. La posibilidad de acceder a la memoria como parte del mapa de direcciones del sistema permite al software del anfitrión configurar los operandos y acceder a los resultados de los cálculos sin la sobrecarga de las copias de datos DMA de E/S tradicionales. Tales copias tradicionales implican llamadas de controlador, interrupciones y accesos de E/S mapeados con memoria (MMIO) que son, todos ellos, ineficientes en relación con accesos de memoria sencillos. Al mismo tiempo, la capacidad de acceder a la memoria anexada al acelerador sin sobrecargas de coherencia de caché puede ser crítica para el tiempo de ejecución de un cómputo descargado. Por ejemplo, en los casos en los que el tráfico de memoria de escritura es considerable, la sobrecarga de coherencia de la caché puede reducir a la mitad el ancho de banda de escritura efectivo que ve un acelerador. La eficiencia de la preparación de los operandos, la eficiencia del acceso a los resultados y la eficiencia del cálculo del acelerador son factores que determinan la eficacia de la descarga del acelerador. Si el coste de la descarga de trabajo (por ejemplo, la configuración de los operandos; la obtención de resultados) es demasiado alta, la descarga puede no ser rentable en absoluto, o puede limitar el acelerador solo a trabajos muy grandes. La eficiencia con la que el acelerador ejecuta un cálculo puede tener el mismo efecto.
Una implementación aplica diferentes técnicas de acceso a la memoria y coherencia dependiendo de la entidad que inicia el acceso a la memoria (por ejemplo, el acelerador, un núcleo, etc.) y la memoria a la que se accede (por ejemplo, la memoria del anfitrión o la memoria del acelerador). Estas técnicas se denominan generalmente como un mecanismo de "polarización de coherencia" que proporciona a la memoria adjunta al acelerador dos conjuntos de flujos de coherencia de caché, uno optimizado para el acceso eficiente del acelerador a su memoria adjunta, y un segundo optimizado para el acceso del anfitrión a la memoria adjunta al acelerador y el acceso compartido del acelerador/anfitrión a la memoria adjunta al acelerador. Además, incluye dos técnicas para cambiar entre estos flujos, una controlada por el software de la aplicación, y otra controlada por sugerencias de hardware autónomo. En ambos conjuntos de flujos de coherencia, el hardware mantiene la coherencia total de la caché.
Como se ilustra en general en la Figura 30, una implementación se aplica a sistemas informáticos que incluyen un acelerador 3001 y uno o más chips de procesador informático con núcleos de procesador y circuitos de E/S 3003, donde el acelerador 3001 está acoplado al procesador a través de un enlace multiprotocolo 2800. En una implementación, el enlace multiprotocolo 3010 es un enlace multiplexado dinámicamente que soporta una pluralidad de protocolos diferentes, incluyendo, pero sin limitación los detallados anteriormente. Debe observarse, sin embargo, que los principios subyacentes de la invención no se limitan a ningún conjunto particular de protocolos. Además, obsérvese que el acelerador 3001 y la E/S del núcleo 3003 pueden estar integrados en el mismo chip semiconductor o en diferentes chips semiconductores, dependiendo de la implementación.
En la implementación ilustrada, un bus de memoria del acelerador 3012 acopla el acelerador 3001 a una memoria del acelerador 3005 y un bus de memoria del anfitrión separado 3011 acopla la E/S del núcleo 3003 a una memoria del anfitrión 3007. Como se ha mencionado, la memoria del acelerador 3005 puede comprender una memoria de alto ancho de banda (HBM) o una DRAM apilada (algunos ejemplos de las cuales se describen en el presente documento) y la memoria de anfitrión 3007 puede comprender una DRAM como una memoria de acceso aleatorio dinámico síncrono de doble tasa de datos (por ejemplo, DDR3 SDRAM, DDR4 SDRAM, etc.). Sin embargo, los principios subyacentes de la invención no se limitan a ningún tipo de memoria o protocolo de memoria en particular.
En una implementación, tanto el acelerador 3001 como el software "anfitrión" que se ejecuta en los núcleos de procesamiento dentro de los chips procesadores 3003 acceden a la memoria del acelerador 3005 usando dos conjuntos distintos de flujos de protocolo, denominados flujos de "polarización del anfitrión" y flujos de "polarización del dispositivo". Como se describe a continuación, una implementación soporta múltiples opciones para modular y/o elegir los flujos de protocolo para accesos de memoria específicos.
Los flujos de polarización de coherencia se implementan, en parte, en dos capas de protocolo en el enlace multiprotocolo 2800 entre el acelerador 3001 y uno de los chips procesadores 3003: una capa de protocolo CAC y una capa de protocolo MA. En una implementación, los flujos de polarización de coherencia están activados por: (a) la utilización de códigos de operación existentes en el protocolo CAC de nuevas formas, (b) la adición de nuevos códigos de operación a una norma MA existente y (c) la adición de soporte para el protocolo MA a un enlace multiprotocolo 3001 (los enlaces anteriores solo incluyen CAC y PCDI). Obsérvese que el enlace multiprotocolo no se limita a soportar solo CAC y MA; en una implementación, simplemente se requiere que soporte al menos esos protocolos.
Como se usa en el presente documento, los flujos "polarización de anfitrión", ilustrados en la Figura 30 son un conjunto de flujos que canalizan todas las solicitudes a la memoria del acelerador 3005 a través del controlador de coherencia convencional 3009 en el chip procesador 3003 al que está unido el acelerador 3001, incluyendo las solicitudes del propio acelerador. Esto hace que el acelerador 3001 tome una ruta tortuosa para acceder a su propia memoria, pero permite que los accesos tanto del acelerador 3001 como de la E/S del núcleo del procesador 3003 se mantengan coherentes usando los controladores de coherencia convencionales del procesador 3009. En una implementación, los flujos usan códigos de operación CAC para emitir solicitudes a través del enlace multiprotocolo a los controladores de coherencia del procesador 3009, de la misma manera o similar a la forma en que los núcleos del procesador 3009 emiten solicitudes a los controladores de coherencia 3009. Por ejemplo, los controladores de coherencia del chip procesador 3009 pueden emitir mensajes de coherencia UPI y CAC (por ejemplo, sondeos) que resultan de las solicitudes del acelerador 3001 a todos los chips de núcleo de procesador pares (por ejemplo, 3003) y a los agentes de procesador internos en nombre del acelerador, tal como lo harían para las solicitudes de un núcleo de procesador 3003. De esta manera, se mantiene la coherencia entre los datos a los que accede el acelerador 3001 y la E/S de los núcleos de procesador 3003.
En una implementación, los controladores de coherencia 3009 también emiten condicionalmente mensajes de acceso a la memoria al controlador de memoria del acelerador 3006 a través del enlace multiprotocolo 2800. Estos mensajes son similares a los mensajes que los controladores de coherencia 3009 envían a los controladores de memoria que son locales a su pastilla de procesador, e incluyen nuevos códigos de operación que permiten que los datos sean devueltos directamente a un agente interno del acelerador 3001, en lugar de forzar que los datos sean devueltos al controlador de coherencia 3009 del procesador del enlace multiprotocolo 2800, y a continuación se devuelvan al acelerador 3001 como una respuesta CAC a través del enlace multiprotocolo 2800.
En una implementación del modo de "polarización de anfitrión" mostrada en la Figura 30, todas las solicitudes de los núcleos del procesador 3003 que se dirigen a la memoria adjunta al acelerador 3005 se envían directamente a los controladores de coherencia de los procesadores 3009, al igual que si se dirigieran a la memoria de anfitrión normal 3007. Los controladores de coherencia 3009 pueden aplicar sus algoritmos de coherencia de caché convencionales y enviar sus mensajes de coherencia de caché convencionales, al igual que lo hacen para los accesos desde el acelerador 3001, y al igual que lo hacen para los accesos a la memoria de anfitrión normal 3007. Los controladores de coherencia 3009 también envían condicionalmente comandos MA a través del enlace multiprotocolo 2800 para esta clase de solicitudes, aunque en este caso, los flujos MA devuelven datos a través del enlace multiprotocolo 2800.
Los flujos de "polarización de dispositivo", ilustrados en la Figura 31, son flujos que permiten al acelerador 3001 acceder a su memoria localmente conectada 3005 sin consultar los controladores de coherencia de caché 3007 del procesador anfitrión. Más específicamente, estos flujos permiten al acelerador 3001 acceder a su memoria localmente conectada a través del controlador de memoria 3006 sin enviar una solicitud a través del enlace multiprotocolo 2800.
En el modo "polarización de dispositivo", las solicitudes de la E/S de los núcleos de procesador 3003 se emiten según la descripción de "polarización de anfitrión" anterior, pero se completan de forma diferente en la porción MA de su flujo. Cuando está en "polarización de dispositivo", las solicitudes del procesador a la memoria adjunta al acelerador 3005 se completan como si se emitieran como solicitudes "sin caché". Esta convención "sin caché" se emplea para que los datos que están sujetos a los flujos de polarización de dispositivo nunca puedan ser almacenados en caché en la jerarquía de caché del procesador. Es este hecho el que permite al acelerador 3001 acceder a los datos de dispositivo polarizado en su memoria 3005 sin consultar los controladores de coherencia de caché 3009 del procesador.
En una implementación, el soporte para el flujo de acceso al núcleo de procesador 3003 "sin caché" se implementa con una respuesta globalmente observada, de uso único ("GO-UO") en el bus CAC de los procesadores. Esta respuesta devuelve una pieza de datos a un núcleo de procesador 3003, e instruye al procesador para que use el valor de los datos solo una vez. Esto evita el almacenamiento en caché de los datos y satisface las necesidades del flujo "sin caché". En los sistemas con núcleos que no soportan la respuesta GO-UO, los flujos "sin caché" pueden implementarse usando una secuencia de respuesta multimensaje en la capa MA del enlace multiprotocolo 2800 y en el bus CAC 3003 del núcleo del procesador.
Específicamente, cuando se descubre que un núcleo de procesador tiene como objetivo una página de "polarización de dispositivo" en el acelerador 3001, el acelerador establece algún estado para bloquear futuras solicitudes a la línea de caché objetivo del acelerador, y envía una respuesta especial "acierto de polarización de dispositivo" en la capa MA del enlace multiprotocolo 2800. En respuesta a este mensaje MA, el controlador de coherencia de caché del procesador 3009 devuelve los datos al núcleo del procesador solicitante 3003 e inmediatamente sigue la devolución de los datos con un mensaje sondeo inválido. Cuando el núcleo del procesador 3003 reconoce la invalidación de sondeo como completa, el controlador de coherencia de caché 3009 envía otro mensaje especial MA "bloqueo de polarización de dispositivo completo" de vuelta al acelerador 3001 en la capa MA del enlace multiprotocolo 2800. Este mensaje de finalización hace que el acelerador 3001 borre el estado de bloqueo antes mencionado.
La Figura 107 ilustra una realización que usa la polarización. En una implementación, la selección entre los flujos de polarización del dispositivo y del anfitrión se controla por una estructura de datos del rastreador de polarización que puede mantenerse como una tabla de polarización 10707 en la memoria del acelerador 3005. Esta tabla de polarización 10707 puede ser una estructura granular de página (es decir, controlada en la granularidad de una página de memoria) que incluye 1 o 2 bits por página de memoria adjunta al acelerador. La tabla de polarización 10707 puede implementarse en un rango de memoria robada de la memoria adjunta al acelerador 3005, con o sin una caché de polarización 10703 en el acelerador (por ejemplo, para almacenar en caché las entradas de uso frecuente/reciente de la tabla de polarización 10707). Como alternativa, toda la tabla de polarización 10707 puede mantenerse dentro del acelerador 3001.
En una implementación, se accede a la entrada de tabla de polarización asociada con cada acceso a la memoria adjunta al acelerador 3005 antes del acceso real a la memoria del acelerador, provocando las operaciones siguientes:
• Las solicitudes locales del acelerador 3001 que encuentran su página en polarización de dispositivo se reenvían directamente a la memoria del acelerador 3005.
• Las solicitudes locales del acelerador 3001 que encuentran su página en polarización de anfitrión se reenvían al procesador 3003 como una petición CAC en el enlace multiprotocolo 2800.
• Las solicitudes de MA del procesador 3003 que encuentran su página en polarización de dispositivo completan la solicitud usando el flujo "sin caché" descrito anteriormente.
• Las solicitudes de MA del procesador 3003 que encuentran su página en polarización de anfitrión completan la solicitud como una lectura de memoria normal.
El estado de desvío de una página se puede cambiar mediante o bien un mecanismo basado en software, o bien un mecanismo basado en software asistido por hardware, o bien, para un conjunto limitado de casos, un mecanismo basado puramente en hardware.
Un mecanismo para cambiar el estado de desvío emplea una llamada de API (por ejemplo, OpenCL), que, a su vez, llama al controlador de dispositivos del acelerador que, a su vez, envía un mensaje al (o pone en cola un descriptor de comandos para) acelerador 3001 que le indica que cambie el estado de desvío y, para algunas transiciones, que realice una operación de vaciado de caché en el anfitrión. La operación de descarga de caché se requiere para una transición desde una polarización de anfitrión a una polarización de dispositivo, pero no se requiere para la transición opuesta.
En algunos casos, es demasiado difícil para el software determinar cuándo hacer las llamadas a la API de transición de polarización e identificar las páginas que requieren transición de polarización. En estos casos, el acelerador puede implementar un mecanismo de "sugerencia" de transición de polarización, en el que detecta la necesidad de una transición de polarización y envía un mensaje a su controlador indicándolo. El mecanismo de sugerencia puede ser tan sencillo como un mecanismo que responda a una búsqueda en la tabla de polarización que se active en los accesos del acelerador a las páginas de polarización del anfitrión o en los accesos del anfitrión a las páginas de polarización del dispositivo, y que señale el evento al controlador del acelerador a través de una interrupción.
Obsérvese que algunas implementaciones pueden requerir un segundo bit de estado de polarización para activar los valores de estado de transición de polarización. Esto permite que los sistemas sigan accediendo a las páginas de memoria mientras esas páginas están en proceso de cambio de polarización (es decir, cuando las cachés se descargan parcialmente, y debe suprimirse la contaminación incremental de la caché debida a solicitudes posteriores)
Un proceso ilustrativo de acuerdo con una implementación se ilustra en la Figura 32. El proceso puede implementarse en las arquitecturas de sistemas y procesadores descritas en el presente documento, pero sin limitación ninguna arquitectura de sistemas o procesadores particular.
En 3201, un conjunto particular de páginas se coloca en la polarización del dispositivo. Como se ha mencionado, esto puede lograrse actualizando las entradas de estas páginas en una tabla de polarización para indicar que las páginas están en polarización del dispositivo (por ejemplo, estableciendo un bit asociado a cada página). En una implementación, una vez que se establece la polarización del dispositivo, se garantiza que las páginas no se almacenan en la memoria caché del anfitrión. En 3202, las páginas se asignan desde la memoria del dispositivo (por ejemplo, el software asigna las páginas iniciando una llamada al controlador/API).
En 3203, los operandos se envían a las páginas asignadas desde un núcleo del procesador. En una de las implantaciones, esto se consigue mediante el software que usa una llamada a la API para voltear las páginas de operandos a polarización de anfitrión (por ejemplo, a través de una llamada a la API de OpenCL). No se requieren copias de datos ni descargas de caché y los datos del operando pueden terminar en esta etapa en alguna ubicación arbitraria de la jerarquía de caché del anfitrión.
En 3204, el dispositivo acelerador utiliza los operandos para generar resultados. Por ejemplo, puede ejecutar comandos y procesar datos directamente desde su memoria local (por ejemplo, 3005 analizado anteriormente). En una implementación, el software usa la API de OpenCL para cambiar las páginas de operandos de vuelta a polarización de dispositivo (por ejemplo, actualizando la tabla de polarización). Como resultado de la llamada a la API, los descriptores de trabajo se envían al dispositivo (por ejemplo, a través de colas de trabajo compartidas y especializadas, como se describe a continuación). El descriptor de trabajo puede ordenar al dispositivo que descargue las páginas de operandos de la caché del anfitrión, lo que da como resultado un vaciado de caché (por ejemplo, ejecutado usando CLFLUSH en el protocolo CAC). En una implementación, el acelerador se ejecuta sin la sobrecarga de coherencia relacionada con el anfitrión y vuelca los datos en las páginas de resultados.
En 3205 se extraen los resultados de las páginas asignadas. Por ejemplo, en una implementación, el software realiza una o más llamadas a la API (por ejemplo, a través de la API OpenCL) para cambiar las páginas de resultados a polarización de anfitrión. Esta acción puede hacer que se cambie algún estado de polarización, pero no provoca ninguna acción de coherencia o descarga de caché. Los núcleos del procesador anfitrión pueden entonces acceder, almacenar en caché y compartir los datos de los resultados según sea necesario. Finalmente, en 3206, se liberan las páginas asignadas (por ejemplo, a través del software).
Un proceso similar en el que los operandos son liberados de uno o más dispositivos de E/S se ilustra en la Figura 33.
En 3301, un conjunto particular de páginas se coloca en la polarización del dispositivo. Como se ha mencionado, esto puede lograrse actualizando las entradas de estas páginas en una tabla de polarización para indicar que las páginas están en polarización del dispositivo (por ejemplo, estableciendo un bit asociado a cada página). En una implementación, una vez que se establece la polarización del dispositivo, se garantiza que las páginas no se almacenan en la memoria caché del anfitrión. En 3302, las páginas se asignan desde la memoria del dispositivo (por ejemplo, el software asigna las páginas iniciando una llamada al controlador/API).
En 3303, los operandos se envían a las páginas asignadas desde un agente de E/S. En una de las implantaciones, esto se consigue mediante el envío por software de una petición DMA a un agente de E/S y el agente de E/S usa almacenes no asignados para escribir datos. En una implementación, los datos nunca se asignan a la jerarquía de la caché del anfitrión y las páginas de destino permanecen en la polarización de dispositivo.
En 3304, el dispositivo acelerador utiliza los operandos para generar resultados. Por ejemplo, el software puede enviar el trabajo al dispositivo acelerador; no es necesario realizar una transición de página (es decir, las páginas permanecen en la polarización del dispositivo). En una implementación, el dispositivo acelerador se ejecuta sin la sobrecarga de coherencia relacionada con el anfitrión y el acelerador vuelca los datos en las páginas de resultados.
En 3305 el agente de E/S extrae los resultados de las páginas asignadas (por ejemplo, bajo la dirección del software). Por ejemplo, el software puede enviar una solicitud DMA al agente de E/S. No se necesita una transición de página, ya que las páginas de origen permanecen en la polarización del dispositivo. En una implementación, el puente de E/S usa solicitudes RdCurr (lectura actual) para obtener una copia no almacenable en caché de los datos de las páginas de resultados.
En algunas implementaciones, las colas de trabajo (WQ) contienen "descriptores" enviados por el software, árbitros utilizados para implementar políticas de calidad de servicio (QoS) y equidad, motores de procesamiento para procesar los descriptores, una interfaz de traducción de direcciones y almacenamiento en caché, y una interfaz de lectura/escritura de memoria. Los descriptores definen el alcance del trabajo a realizar. Como se ilustra en la Figura 34, en una implementación, hay dos tipos diferentes de colas de trabajo: colas de trabajo especializadas 3400 y colas de trabajo compartidas 3401. Las colas de trabajo especializadas 3400 almacenan descriptores para una sola aplicación 3413 mientras que las colas de trabajo compartidas 3401 almacenan descriptores enviados por múltiples aplicaciones 3410-3412. Una interfaz de hardware/arbitraje 3402 despacha descriptores de las colas de trabajo 3400­ 3401 a los motores de procesamiento del acelerador 3405 de acuerdo con una política de arbitraje especificada (por ejemplo, basándose en los requisitos de procesamiento de cada aplicación 3410-3413 y en las políticas de QoS/equidad).
Las Figuras 108A-B ilustran registros de espacio de E/S mapeados en memoria (MMIO) usados con implementaciones basadas en colas de trabajo. El registro de versión 10807 informa de la versión de esta especificación de arquitectura que soporta el dispositivo.
El registro de capacidades generales (GENCAP) 10808 especifica las capacidades generales del dispositivo, tal como el tamaño máximo de transferencia, el tamaño máximo de lote, etc. La tabla B enumera diversos parámetros y valores que pueden especificarse en el registro GENCAP.
TABLA B
Figure imgf000040_0002
En una implementación, el registro de capacidades de colas de trabajo (WQCAP) 10810 especifica las capacidades de las colas de trabajo, tales como el soporte para modos de operación especializados y/o compartidos, el número de motores, el número de colas de trabajo. En la tabla C se enumeran diversos parámetros y valores que pueden configurarse.
TABLA C
Figure imgf000040_0001
(continuación)
Figure imgf000041_0001
En una implementación, el registro de capacidad de operaciones (OPCAP) 10811 es una máscara de bits para especificar los tipos de operación soportados por el dispositivo. Cada bit corresponde al tipo de operación con el mismo código que la posición del bit. Por ejemplo, el bit 0 de este registro corresponde a la operación No-op (código 0). El bit se establece si se soporta la operación, y se borra si la operación no es compatible.
TABLA D
Figure imgf000041_0002
En una implementación, el registro de configuración general (GENCFG) 10812 especifica las etiquetas de dirección del canal virtual (VC). Véase la Tabla E a continuación.
TABLA E
Figure imgf000041_0003
En una implementación, el registro de control general (GENCTRL) 10813 indica si se generan interrupciones por errores de hardware o de software. Véase la tabla F a continuación.
TABLA F
Figure imgf000042_0001
En una implementación, el registro de activación de dispositivos (ACTIVACIÓN) almacena códigos de error, indicadores de si los dispositivos están activados y valores de reinicio de dispositivos. Para más detalles, véase la tabla G a continuación.
TABLA G
Figure imgf000043_0001
En una implementación, un registro de causa de interrupción (INTCAUSE) almacena valores que indican la causa de una interrupción. Véase la tabla H a continuación.
TABLA H
Figure imgf000043_0002
En una implementación, el registro de comandos (CMD) 10814 se usa para enviar los comandos drenar WQ, drenar PASID y drenar todo. El campo abortar indica si la operación solicitada es un drenaje o un aborto. Antes de escribir en este registro, el software puede garantizar que se ha completado cualquier comando enviado previamente a través de este registro. Antes de escribir en este registro, el software puede configurar el registro de configuración de comandos y también el registro de dirección de registro de finalización de comandos si se solicita un registro de finalización.
El comando drenar todo drena o aborta todos los descriptores pendientes en todas las WQ y todos los motores. El comando drenar PASID drena o aborta los descriptores que utilizan el PASID especificado en todas las WQ y todos los motores. Drenar WQ drena o aborta todos los descriptores en la WQ especificada. Dependiendo de la implementación, cualquier comando de drenaje puede esperar a que se completen otros descriptores además de los descriptores que debe esperar.
Si el campo abortar es 1, el software está solicitando que se abandonen los descriptores afectados. Sin embargo, el hardware puede completar aún algunos o todos ellos. Si se abandona un descriptor, no se escribe ningún registro de finalización y no se genera ninguna interrupción de finalización para ese descriptor. Pueden producirse algunos o todos los demás accesos a la memoria.
La finalización de un comando se indica generando una interrupción de finalización (si se solicita) y borrando el campo de estado de este registro. En el momento en que se señala la finalización, todos los descriptores afectados se completan o se abandonan, y no se generarán más traducciones de direcciones, lecturas de memoria, escrituras de memoria o interrupciones debido a cualquier descriptor afectado. Véase la tabla I a continuación.
TABLA I
Figure imgf000044_0001
En una implementación, el registro de estado de error de software (SWERROR) 10815 almacena múltiples tipos diferentes de errores, tales como: un error en la presentación de un descriptor; un error al traducir una dirección de registro de finalización en un descriptor; un error al validar un descriptor, si la bandera de dirección de registro de finalización válida en el descriptor es 0; y un error durante el procesamiento de un descriptor, tal como un fallo de página, si la bandera de dirección de registro de finalización válida en el descriptor es 0. Véase la tabla J a continuación.
Figure imgf000045_0001
(continuación)
Figure imgf000046_0001
TABLA J
En una implementación, el registro de estado de error de hardware (HWERROR) 10816 de manera similar al registro de estado de error de software (véase anteriormente).
En una implementación, los registros de configuración de grupo (GRPCFG) 10817 almacenan datos de configuración para cada cola de trabajo/grupo de motores (véase las Figuras 36-37). En particular, la tabla de configuración de grupos es una matriz de registros en BAR0 que controla la asignación de colas de trabajo a los motores. Hay el mismo número de grupos que de motores, pero el software puede configurar el número de grupos que necesite. Cada grupo activo contiene una o varias colas de trabajo y uno o más motores. Cualquier grupo no utilizado debe tener tanto el campo de WQ como el campo de motores igual a 0. Los descriptores enviados a cualquier WQ de un grupo pueden procesarse por cualquier motor en el grupo. Cada cola de trabajo activa debe estar en un solo grupo. Una cola de trabajo activa es aquella para la que el campo de tamaño de WQ del registro WQCFG correspondiente es distinto de cero. Cualquier motor que no esté en un grupo está inactivo.
Cada registro GRPCFG 10817 puede dividirse en tres subregistros, y cada subregistro es una o más palabras de 32 bits (véanse las Tablas K-M). Estos registros pueden ser de solo lectura mientras el dispositivo esté activado. También son de solo lectura si el campo de soporte de configuración de cola de trabajo de WQCAP es 0.
Los desplazamientos de los subregistros en BAR0, para cada grupo G, 0 < G < número de motores, son los siguientes en una implementación:
Figure imgf000046_0003
TABLA K
Figure imgf000046_0002
TABLA L
Figure imgf000047_0002
TABLA M
Figure imgf000047_0003
En una implementación, los registros de configuración de colas de trabajo (WQCFG) 10818 almacenan datos que especifican la operación de cada cola de trabajo. La tabla de configuración de WQ es una matriz de registros de 16 bytes en BAR0. El número de registros de configuración de WQ coincide con el campo de número de WQ en WQCAP.
Cada registro WQCFG de 16 bytes se divide en cuatro subregistros de 32 bits, que también pueden leerse o escribirse usando operaciones de lectura o escritura alineadas de 64 bits.
Cada subregistro WQCFG-A es de solo lectura mientras el dispositivo está activado o si el campo de soporte de configuración de cola de trabajo de WQCAP es 0.
Cada WQCFG-B es escribible en cualquier momento a menos que el campo de soporte de configuración de cola de trabajo de WQCAP sea 0. Si el campo de umbral de WQ contiene un valor mayor que el tamaño de WQ en el momento en que se activa la WQ, la WQ no se activa y el código de error de WQ se establece a 4. Si el campo de umbral de WQ se escribe con un valor mayor que el tamaño de WQ mientras la WQ está activada, la WQ se desactiva y el código de error WQ se establece a 4.
Cada subregistro WQCFG-C es de solo lectura mientras la WQ está activada. Puede escribirse antes o al mismo tiempo que la activación de WQ a 1. Los siguientes campos son de solo lectura en todo momento si el campo de soporte de configuración de cola de trabajo de WQCAP es 0: Modo de WQ, Bloqueo de WQ en caso de fallo y prioridad de WQ. Los siguientes campos de WQCFG-C se pueden escribir cuando la WQ no está activada, incluso si el campo de soporte de configuración de cola de trabajo de WQCAP es 0: WQ PASID y WQ U/S.
Cada sub-registro WQCFG-D es escribible en cualquier momento. Sin embargo, es un error establecer la activación de WQ a 1 cuando el dispositivo no está activado.
Cuando la activación de WQ se establece a 1, los campos WQ activada y código de error de WQ se borran. Posteriormente, se establecerá WQ activada o código de error de WQ con un valor distinto de cero, indicando si la WQ se ha activado con éxito o no.
La suma de los campos de tamaño de WQ de todos los registros WQCFG no debe ser mayor que el campo de tamaño de WQ total de GENCAP. Esta restricción se comprueba en el momento de activar el dispositivo. Las WQ para las que el campo de tamaño de WQ es 0 no pueden activarse, y todos los demás campos de tales registros WQCFG se ignoran. El campo de tamaño WQ es de solo lectura mientras el dispositivo está activado. Véase la Tabla N para los datos relacionados con cada uno de los subregistros.
TABLA N
Figure imgf000047_0001
Figure imgf000048_0001
Figure imgf000049_0001
En una implementación, los registros de control de interrupción de la ocupación de la cola de trabajo 10819 (uno por cola de trabajo (WQ)) permiten al software solicitar una interrupción cuando la ocupación de la cola de trabajo cae a un valor de umbral especificado. Cuando la activación de la interrupción de la ocupación de la WQ para una WQ es 1 y la ocupación actual de la WQ es igual o menor que el límite de ocupación de la WQ, se pueden realizar las siguientes acciones:
1. El campo de activación de interrupción de ocupación de WQ se borra.
2. Se establece el bit 3 del registro de motivos de interrupción 1.
3. Si el bit 3 del registro de Interrupción de motivo era 0 antes de la etapa 2, se genera una interrupción usando la entrada 0 de la tabla MSI-X.
4. Si el registro se escribe con activación = 1 y límite > la ocupación actual de WQ, la interrupción se genera inmediatamente. En consecuencia, si el registro se escribe con activación = 1 y límite > tamaño de WQ, la interrupción se genera siempre inmediatamente.
TABLA O
Figure imgf000049_0002
En una implementación, los registros de estado de la cola de trabajo (uno por WQ) 10820 especifican el número de entradas actualmente en cada WQ. Este número puede cambiar cada vez que se envían descriptores a la cola o se despachan desde ella, por lo que no se puede confiar en él para determinar si hay espacio en la WQ.
En una implementación, las entradas de MSI-X 10821 almacenan datos de la tabla MSI-X. El desplazamiento y el número de entradas están en la capacidad de MSI-X. El número sugerido de entradas es el número de WQ más 2.
En una implementación, la matriz de bits pendientes de MSI-X 10822 almacena el desplazamiento y el número de entradas están en la capacidad de MSI-X.
En una implementación, las entradas de almacenamiento de mensajes de interrupción 10823 almacenan mensajes de interrupción en una estructura de tabla. El formato de esta tabla es similar al de la tabla MSI-X definida por PCI, pero el tamaño no está limitado a 2048 entradas. Sin embargo, el tamaño de esta tabla puede variar entre diferentes implementaciones de DSA y puede ser menor que 2048 entradas en algunas implementaciones. En una implementación, el número de entradas se encuentra en el campo de tamaño de almacenamiento de mensajes de interrupción del registro de capacidad general. Si la capacidad de almacenamiento de mensajes de interrupción es 0, esta tabla no está presente. Para que DSA soporte un gran número de máquinas virtuales o contenedores, el tamaño de la tabla soportada debe ser significativo.
En una implementación, el formato de cada entrada en el IMS es el que se expone a la Tabla P a continuación:
TABLA P
Figure imgf000050_0001
La Figura 35 ilustra una implementación de un dispositivo acelerador de flujo de datos (DSA) que comprende múltiples colas de trabajo 3511-3512 que reciben descriptores enviados a través de una interfaz de tejido de E/S 3501 (por ejemplo, tal como el enlace multiprotocolo 2800 descrito anteriormente). DSA usa la interfaz de tejido de E/S 3501 para recibir solicitudes de trabajo aguas abajo de los clientes (tales como núcleos de procesador, agentes de entrada/salida (E/S) de pares (tales como un controlador de interfaz de red (NIC)), y/o solicitudes de descarga encadenada de software) y para operaciones de lectura, escritura y traducción de direcciones aguas arriba. La implementación ilustrada incluye un árbitro 3513 que arbitra entre las colas de trabajo y despacha un descriptor de trabajo a uno de una pluralidad de motores 3550. El funcionamiento del árbitro 3513 y de las colas de trabajo 3511­ 1012 puede configurarse mediante un registro de configuración de colas de trabajo 3500. Por ejemplo, el árbitro 3513 puede estar configurado para implementar diversas políticas de QoS y/o de equidad para despachar descriptores de cada una de las colas de trabajo 3511-1012 a cada uno de los motores 3550.
En una implementación, algunos de los descriptores puestos en cola en las colas de trabajo 3511-3512 son descriptores de lote 3515 que contienen/identifican un lote de descriptores de trabajo. El árbitro 3513 reenvía los descriptores por lotes a una unidad de procesamiento por lotes 3516 que procesa los descriptores por lotes leyendo la matriz de descriptores 3518 de la memoria, usando las direcciones traducidas a través de la caché de traducción 3520 (potencialmente otros servicios de traducción de direcciones en el procesador). Una vez identificada la dirección física, el circuito de lectura/escritura de datos 3540 lee el lote de descriptores de la memoria.
Un segundo árbitro 3519 arbitra entre los lotes de descriptores de trabajo 3518 proporcionados por la unidad de procesamiento de lotes 3516 y los descriptores de trabajo individuales 3514 recuperados de las colas de trabajo 3511 -3512 y envía los descriptores de trabajo a una unidad de procesamiento de descriptores de trabajo 3530. En una implementación, la unidad de procesamiento de descriptores de trabajo 3530 tiene etapas para leer la memoria (a través de la unidad L/E de datos 3540), realizar la operación solicitada en los datos, generar datos de salida y escribir datos de salida (a través de la unidad L/E de datos 3540), registros de finalización y mensajes de interrupción.
En una implementación, la configuración de la cola de trabajo permite que el software configure cada WQ (a través de un registro de configuración de WQ 3500) como una cola de trabajo compartida (SWQ) que recibe descriptores usando instrucciones ENQCMD/S no publicadas o como una cola de trabajo especializada (DWQ) que recibe descriptores utilizando instrucciones MOVDIR64B publicadas. Como se mencionó anteriormente con respecto a la Figura 34, una DWQ puede procesar descriptores de trabajo y descriptores de lotes enviados desde una sola aplicación, mientras que una SWQ puede compartirse entre múltiples aplicaciones. El registro de configuración de WQ 3500 también permite al software controlar qué WQ 3511-3512 alimentan a qué motores aceleradores 3550 y las prioridades relativas de las WQ 3511-3512 que alimentan a cada motor. Por ejemplo, se puede especificar un conjunto ordenado de prioridades (por ejemplo, alta, media, baja; 1, 2, 3, etc.) y los descriptores generalmente pueden ser despachados desde colas de trabajo de mayor prioridad antes o con mayor frecuencia que los despachos desde colas de trabajo de menor prioridad. Por ejemplo, con dos colas de trabajo, identificadas como de alta y baja prioridad, por cada 10 descriptores a despachar, 8 de los 10 descriptores pueden ser despachados desde la cola de trabajo de alta prioridad mientras que 2 de los 10 descriptores son despachados desde la cola de trabajo de baja prioridad. Se pueden usar otras técnicas para conseguir diferentes niveles de prioridad entre las colas de trabajo 3511 -3512.
En una implementación, el acelerador de envío por flujo continuo de datos (DSA) es compatible por software con un mecanismo de configuración PCI Express, e implementa una encabezado PCI y un espacio extendido en su conjunto de registros de configuración mapeada. Los registros de configuración pueden programarse a través de CFC/CF8 o MMCFG desde el complejo raíz. Todos los registros internos pueden ser accesibles también a través de las interfaces JTAG o SMBus.
En una implementación, el dispositivo DSA usa registros mapeados en memoria para controlar su operación. Los registros de capacidad, configuración y envío de trabajos (portales) son accesibles a través de las regiones MMIO definidas por los registros BAR0, BAR2 y BAR4 (descritos a continuación). Cada portal puede estar en una página 4K separada para que puedan ser mapeados independientemente en diferentes espacios de direcciones (clientes) usando las tablas de páginas del procesador.
Como se ha mencionado, el software especifica el trabajo para DSA a través de descriptores. Los descriptores especifican el tipo de operación que debe realizar el DSA, las direcciones de las memorias intermedias de datos y de estado, los operandos inmediatos, los atributos de finalización, etc. (más adelante se exponen los detalles del formato de descriptor). Los atributos de finalización especifican la dirección en la que se debe escribir el registro de finalización y la información necesaria para generar una interrupción de finalización opcional.
En una implementación, DSA evita mantener el estado específico del cliente en el dispositivo. Toda la información para procesar un descriptor viene en el propio descriptor. Esto mejora su capacidad de compartición entre aplicaciones en modo usuario, así como entre diferentes máquinas virtuales (o contenedores de máquinas) en un sistema virtualizado.
Un descriptor puede contener una operación y los parámetros asociados (llamado descriptor de trabajo), o puede contener la dirección de una matriz de descriptores de trabajo (llamado descriptor de lote). El software prepara el descriptor en la memoria y lo envía a una cola de trabajo (WQ) 3511-3512 del dispositivo. El descriptor se envía al dispositivo mediante una instrucción MOVDIR64B, ENQCMD o En QCMDS, dependiendo del modo de WQ y del nivel de privilegio del cliente.
Cada WQ 3511-3512 tiene un número fijo de ranuras y, por lo tanto, puede llenarse con una carga pesada. En una implementación, el dispositivo proporciona la realimentación necesaria para ayudar al software a implementar el control de flujo. El dispositivo despacha los descriptores de las colas de trabajo 3511-3512 y los envía a los motores para su posterior procesamiento adicional. Cuando el motor 3550 completa un descriptor o encuentra ciertos fallos o errores que resultan un aborto, notifica al software anfitrión ya sea escribiendo en un registro de finalización en la memoria del anfitrión, emitiendo una interrupción, o ambos.
En una implementación, cada cola de trabajo es accesible a través de múltiples registros, cada uno en una página separada de 4 KB en el espacio MMIO del dispositivo. Un registro de envío de trabajo para cada WQ se denomina "portal sin privilegios" y se asigna al espacio de usuario para ser utilizado por los clientes en modo usuario. Otro registro de envío de trabajo se llama "portal con privilegio" y es utilizado por el controlador en modo de núcleo. El resto son portales de invitados, y son utilizados por clientes en modo de núcleo en máquinas virtuales.
Como se ha mencionado, cada cola de trabajo 3511-3512 puede configurarse para ejecutarse en uno de los dos modos, especializado o compartido. DSA expone losbits de capacidad en el registro de capacidad de cola de trabajo para indicar el soporte de los modos especializado y compartido. También expone un control en los registros de configuración de la cola de trabajo 3500 para configurar cada WQ para que funcione en uno de los modos. El modo de una WQ solo se puede cambiar mientras la WQ está desactivada, es decir, (WQCFG.Enabled = 0). A continuación, se exponen detalles adicionales del registro de capacidades de WQ y de los registros de configuración de WQ.
En una implementación, en modo compartido, un cliente DSA usa las instrucciones ENQCMD o ENQCMDS para enviar descriptores a la cola de trabajo. ENQCMD y ENQCMDS usan una escritura no publicada de 64 bytes y esperan una respuesta del dispositivo antes de finalizar. El DSA devuelve un "éxito" (por ejemplo, al cliente/aplicación solicitante) si hay espacio en la cola de trabajo, o un "reintento" si la cola de trabajo está llena. Las instrucciones ENQCMD y ENQCMDS pueden devolver el estado del envío del comando en una bandera cero (0 indica éxito y 1 indica reintento). Usando las instrucciones ENQCMD y ENQCMDS, múltiples clientes pueden enviar directa y simultáneamente descriptores a la misma cola de trabajo. Puesto que el dispositivo proporciona esta realimentación, los clientes pueden saber si sus descriptores fueron aceptados.
En el modo compartido, el DSA puede reservar alguna de la capacidad de SWQ para los envíos a través del portal con privilegio para los clientes en modo de núcleo. El envío de trabajos a través del portal sin privilegios se acepta hasta que el número de descriptores en la SWQ alcanza el umbral configurado para la SWQ. La emisión de trabajos a través del portal con privilegios se acepta hasta que se llene la SWQ. La emisión de trabajos a través de los portales de invitados está limitada por el umbral de la misma manera que el portal sin privilegios.
Si la instrucción ENQCMD o ENQCMDS devuelve "éxito", el descriptor ha sido aceptado por el dispositivo y puesto en cola para su procesamiento. Si la instrucción devuelve "reintento", el software puede intentar volver a enviar el descriptor a la SWQ, o si era un cliente en modo usuario que utilizaba el portal sin privilegios, puede solicitar al controlador en modo de núcleo que envíe el descriptor en su nombre usando el portal con privilegios. Esto ayuda a evitar la denegación de servicio y proporciona garantías de avance. Como alternativa, el software puede usar otros métodos (por ejemplo, usar la CPU para realizar el trabajo) si la SWQ está llena.
Los clientes/aplicaciones son identificados por el dispositivo mediante un ID de 20 bits llamado ID del espacio de direcciones del proceso (PASID). El PASID se usa por el dispositivo para buscar direcciones en la TLB del dispositivo 1722 y para enviar solicitudes de traducción de direcciones o de páginas a la IOMMU 1710 (por ejemplo, a través del enlace multiprotocolo 2800). En el modo compartido, el PASID que se usará con cada descriptor está contenido en el campo de PASID del descriptor. En una implementación, ENQCMD copia el PASID del hilo actual de un registro particular (por ejemplo, MSR de PASID) en el descriptor, mientras que ENQCMDS permite al software de modo supervisor copiar el PASID en el descriptor.
En el modo "especializado", un cliente DSA puede usar la instrucción MOVDIR64B para enviar descriptores a la cola de trabajo del dispositivo. MOVDIR64B usa una escritura publicada de 64 bytes y la instrucción se completa más rápidamente debido a la naturaleza publicada de la operación de escritura. Para las colas de trabajo especializadas, DSA puede exponer el número total de ranuras en la cola de trabajo y depende del software para proporcionar el control de flujo. El software se encarga de hacer un seguimiento del número de descriptores presentados y completados, para detectar una condición de cola de trabajo llena. Si el software envía erróneamente un descriptor a una WQ especializada cuando no hay espacio en la cola de trabajo, el descriptor se abandona y el error puede registrarse (por ejemplo, en el registro de errores del software).
Puesto que la instrucción MOVDIR64B no rellena el PASID como lo hacen las instrucciones ENQCMD o ENQCMDS, el campo PASID del descriptor no puede usarse en modo especializado. El DSA puede ignorar el campo PASID en los descriptores enviados a las colas de trabajo especializadas, y usa el campo PASID de WQ del registro de configuración de WQ 3500 para hacer la traducción de direcciones en su lugar. En una implementación, el campo PASID de WQ se establece por el controlador de DSA cuando configura la cola de trabajo en modo especializado.
Aunque el modo especializado no comparte una única DWQ por múltiples clientes/aplicaciones, un dispositivo DSA puede configurarse para tener múltiples DWQ y cada una de las DWQ puede asignarse independientemente a los clientes. Además, las DWQ pueden configurarse para tener el mismo o diferentes niveles de QoS para proporcionar diferentes niveles de rendimiento para diferentes clientes/aplicaciones.
En una implementación, un acelerador de flujo de datos (DSA) contiene dos o más motores 3550 que procesan los descriptores enviados a las colas de trabajo 3511-1012. Una implementación de la arquitectura DSA incluye 4 motores, numerados del 0 al 3. Los motores 0 y 1 pueden utilizar cada uno de ellos el ancho de banda completo del dispositivo (por ejemplo, 30 GB/s para lecturas y 30 GB/s para escrituras). Por supuesto, el ancho de banda combinado de todos los motores también está limitado al ancho de banda máximo disponible en el dispositivo.
En una implementación, el software configura las WQ 3511 -3512 y los motores 3550 en grupos utilizando los registros de configuración de grupos. Cada grupo contiene una o más WQ y uno o más motores. El DSA puede usar cualquier motor de un grupo para procesar un descriptor enviado a cualquier WQ del grupo y cada WQ y cada motor pueden estar en un solo grupo. El número de grupos puede ser el mismo que el número de motores, por lo que cada motor puede estar en un grupo separado, pero no es necesario utilizar todos los grupos si alguno contiene más de un motor.
Aunque la arquitectura de DSA permite una gran flexibilidad a la hora de configurar las colas de trabajo, los grupos y los motores, el hardware puede estar estrechamente diseñado para su uso en configuraciones específicas. Los motores 0 y 1 pueden configurarse de dos maneras diferentes, dependiendo de los requisitos del software. Una configuración recomendada es colocar los motores 0 y 1 en el mismo grupo. El hardware usa cualquier motor para procesar los descriptores de cualquier cola de trabajo del grupo. En esta configuración, si un motor se bloquea debido a una traducción de direcciones de memoria de alta latencia o a un fallo de página, el otro motor puede seguir operando y maximizar el rendimiento del dispositivo en general.
La Figura 36 muestra dos colas de trabajo 3621-3622 y 3623-3624 en cada grupo 3611 y 3612, respectivamente, pero puede haber cualquier número hasta el número máximo de WQ soportadas. Las WQ de un grupo pueden ser WQ compartidas con diferentes prioridades, o una WQ compartida y las otras WQ especializadas, o múltiples WQ especializadas con las mismas o diferentes prioridades. En el ejemplo ilustrado, el grupo 3611 es atendido por los motores 0 y 13601 y el grupo 3612 es atendido por los motores 2 y 33602.
Como se ilustra en la Figura 37, otra configuración usando los motores 0 3700 y 13701 es colocarlos en grupos separados 3710 y 3711, respectivamente. Del mismo modo, el grupo 23712 se asigna al motor 23702 y el grupo 3 se asigna al motor 33703. Además, el grupo 03710 está compuesto por dos colas de trabajo 3721 y 3722; el grupo 1 3711 está compuesto por la cola de trabajo 3723; la cola de trabajo 23712 está compuesta por la cola de trabajo 3724; y el grupo 33713 está compuesto por la cola de trabajo 3725.
El software puede elegir esta configuración cuando quiere reducir la probabilidad de que las operaciones sensibles a la latencia se bloqueen detrás de otras operaciones. En esta configuración, el software envía operaciones sensibles a la latencia a la cola de trabajo 3723 conectada al motor 13702, y otras operaciones a las colas de trabajo 3721 -3722 conectadas al motor 03700.
El motor 23702 y el motor 33703 pueden usarse, por ejemplo, para escribir en una memoria no volátil de gran ancho de banda, tal como la memoria de cambio de fase. La capacidad de ancho de banda de estos motores puede dimensionarse para que coincida con el ancho de banda de escritura esperado de este tipo de memoria. Para este uso, los bits 2 y 3 del registro de configuración de motores deben ponerse a 1, lo que indica que el canal virtual 1 (VC1) debe usarse para el tráfico de estos motores.
En una plataforma sin memoria no volátil de alto ancho de banda (por ejemplo, memoria de cambio de fase) o cuando el dispositivo DSA no se usa para escribir en este tipo de memoria, los motores 2 y 3 pueden no utilizarse. Sin embargo, es posible que el software los utilice como rutas adicionales de baja latencia, siempre que las operaciones presentadas sean tolerantes con el ancho de banda limitado.
A medida que cada descriptor llega a la cabecera de la cola de trabajo, puede ser retirado por el planificador/árbitro 3513 y reenviado a uno de los motores del grupo. Para un descriptor de lote 3515, que se refiere a los descriptores de trabajo 3518 en la memoria, el motor obtiene la matriz de descriptores de trabajo de la memoria (es decir, usando la unidad de procesamiento de lotes 3516).
En una implementación, para cada descriptor de trabajo 3514, el motor 3550 obtiene previamente la traducción para la dirección del registro de finalización, y pasa la operación a la unidad de procesamiento de descriptores de trabajo 3530. La unidad de procesamiento de descriptores de trabajo 3530 utiliza la TLB de dispositivo 1722 y la IOMMU 1710 para las traducciones de direcciones de origen y destino, lee los datos de origen, realiza la operación especificada y escribe los datos de destino de vuelta a la memoria. Cuando la operación se completa, el motor escribe el registro de finalización en la dirección de finalización pretraducida y genera una interrupción, si así lo solicita el descriptor de trabajo.
En una implementación, las múltiples colas de trabajo de DSA pueden usarse para proporcionar múltiples niveles de calidad de servicio (QoS). La prioridad de cada WQ puede especificarse en el registro de configuración de WQ 3500. Las prioridades de las WQ son relativas a otras WQ del mismo grupo (por ejemplo, no tiene sentido el nivel de prioridad de una WQ que está en un grupo por sí misma). Las colas de trabajo de un grupo pueden tener las mismas o diferentes prioridades. Sin embargo, no tiene sentido configurar varias WQ compartidas con la misma prioridad en el mismo grupo, ya que una sola SWQ serviría para el mismo propósito. El planificador/árbitro 3513 envía los descriptores de trabajo de las colas de trabajo 3511-3512 a los motores 3550 de acuerdo con su prioridad.
La Figura 38 ilustra una implementación de un descriptor 1300 que incluye un campo de operación 3801 para especificar la operación a realizar, una pluralidad de banderas 3802, un campo de identificador de espacio de direcciones de proceso (PASID) 3803, un campo de dirección de registro de finalización 3804, un campo de dirección de origen 3805, un campo de dirección de destino 3806, un campo de interrupción de finalización 3807, un campo de tamaño de transferencia 3808, y (potencialmente) uno o más campos específicos de operación 3809. En una implementación, hay tres banderas: Dirección de registro de finalización válida, solicitar registro de finalización y solicitar interrupción de finalización.
Los campos comunes incluyen tanto los campos confiables como los no confiables. Los campos confiables son siempre de confianza para el dispositivo DSA, ya que son rellenados por la CPU o por software con privilegios (anillo 0 o VMM) en el anfitrión. Los campos no confiables se suministran directamente por los clientes DSA.
En una implementación, los campos de confianza incluyen el campo PASID 3803, el campo reservado 3811, y el campo U/S (usuario/supervisor) 3810 (es decir, 4 Bytes comenzando en un desplazamiento de 0). Cuando se envía un descriptor con la instrucción ENQCMD, estos campos del descriptor de origen pueden ignorarse. El valor contenido en un MSR (por ejemplo, MSR de PASID) puede colocarse en estos campos antes de que el descriptor se envíe al dispositivo.
En una implementación, cuando se envía un descriptor con la instrucción ENQCMDS, estos campos en el descriptor de origen se inicializan por el software. Si la capacidad PASID de PCI Express no está activada, el campo U/S 3810 se establece a 1 y el campo PASID 3803 se establece a 0.
Cuando se envía un descriptor con la instrucción MOVDIR64B, estos campos del descriptor pueden ignorarse. En cambio, el dispositivo usa los campos U/S de WQ y PASID de WQ del registro de configuración de WQ 3500.
Estos campos pueden ignorarse para cualquier descriptor de un lote. Los campos correspondientes del descriptor de lote 3515 se usan para cada descriptor 3518 del lote. La tabla Q proporciona una descripción y posiciones de bits para cada uno de estos campos confiables.
TABLA Q (campos confiables del descriptor)
Figure imgf000053_0001
En la tabla R se enumeran las operaciones realizadas en una implementación de acuerdo con el campo de operación 3801 del descriptor.
TABLA R (tipos de operación)
Figure imgf000054_0002
En la tabla S se enumeran las banderas usadas en una implementación del descriptor.
TABLA S (Banderas)
Figure imgf000054_0001
Figure imgf000055_0001
Figure imgf000056_0001
En una implementación, la dirección del registro de finalización 3804 especifica la dirección del registro de finalización. El registro de finalización puede tener 32 bytes y la dirección del registro de finalización está alineada en un límite de 32 bytes. Si la bandera de dirección de registro de finalización válida es 0, este campo está reservado. Si la bandera de solicitud de registro de finalización es 1, se escribe un registro de finalización en esta dirección al terminar la operación. Si el registro de finalización de solicitud es 0, se escribe un registro de finalización en esta dirección solo si hay un fallo o error de página.
Para cualquier operación que produzca un resultado, tal como la comparación, las banderas de dirección de registro de finalización válida y de solicitud de registro de finalización deben ser ambas 1 y la dirección de registro de finalización debe ser válida.
Para cualquier operación que use direcciones virtuales, la dirección de registro de finalización debe ser válida, esté o no establecida la bandera de solicitud de registro de finalización, de modo que pueda escribirse un registro de finalización en caso de que se produzca un fallo o error de página.
Para obtener los mejores resultados, este campo debe ser válido en todos los descriptores, ya que permite que el dispositivo informe de los errores al software que envió el descriptor. Si esta bandera es 0 y se produce un error inesperado, el error se comunica al registro SWERROR, y el software que envió la solicitud puede no ser notificado del error.
El campo de dirección de registro de finalización 3804 se ignora para los descriptores de un lote si la bandera de activación de cola de finalización está establecida en el descriptor de lote; se usa la dirección de la cola de finalización en el descriptor de lote.
En una implementación, para las operaciones que leen datos de la memoria, el campo de dirección de origen 3805 especifica la dirección de los datos de origen. No hay ningún requisito de alineación para la dirección de origen. Para las operaciones que escriben datos en la memoria, el campo de dirección de destino 3806 especifica la dirección de la memoria intermedia de destino. No hay ningún requisito de alineación para la dirección de destino. Para algunos tipos de operaciones, este campo se usa como dirección de una segunda memoria intermedia de origen.
En una implementación, el campo de tamaño de transferencia 3808 indica el número de bytes a leer de la dirección de origen para realizar la operación. El valor máximo de este campo puede ser 232-1, pero el tamaño máximo de transferencia permitido puede ser menor, y debe determinarse a partir del campo de tamaño máximo de transferencia del registro de capacidad general. El tamaño de transferencia no debe ser 0. Para la mayoría de los tipos de operaciones, no hay ningún requisito de alineación para el tamaño de transferencia. Las excepciones se indican en las descripciones de las operaciones.
En una implementación, si la bandera de usar almacenamiento de mensajes de interrupción es 1, el campo de manejador de interrupción de finalización 3807 especifica la entrada de almacenamiento de mensajes de interrupción que se usará para generar una interrupción de finalización. El valor de este campo debe ser menor que el valor del campo tamaño de almacenamiento de mensajes de interrupción en GENCAP. En una implementación, el campo de manejador de interrupción de finalización 3807 está reservado bajo cualquiera de las siguientes condiciones: la bandera de usar almacenamiento de mensajes de interrupción es 0; la bandera de interrupción de solicitud de finalización es 0; el bit U/S es 0; el campo de soporte de almacenamiento de mensajes de interrupción del registro de capacidad general es 0; o el descriptor se envió a través de un portal de invitados.
Como se ilustra en la Figura 39, una implementación del registro de finalización 3900 es una estructura de 32 bytes en memoria que el DSA escribe cuando la operación se completa o encuentra un error. La dirección del registro de finalización debe estar alineada a 32 bytes.
Esta sección describe los campos del registro de finalización que son comunes a la mayoría de los tipos de operaciones. La descripción de cada tipo de operación incluye un diagrama de registro de finalización si el formato difiere de éste. Más adelante se describen otros campos específicos de la operación. El registro de finalización 3900 puede ser siempre de 32 bytes aunque no se necesiten todos los campos. El registro de finalización 3900 contiene suficiente información para continuar la operación si se ha completado parcialmente debido a un fallo de página.
El registro de finalización puede implementarse como una estructura alineada de 32 bytes en la memoria (identificada por la dirección del registro de finalización 3804 del descriptor 3800). El registro de finalización 3900 contiene el campo de estado de finalización 3904 para indicar si la operación ha finalizado. Si la operación se ha completado con éxito, el registro de finalización puede contener el resultado de la operación, si lo hay, dependiendo del tipo de operación. Si la operación no se ha completado con éxito, el registro de finalización contiene información sobre fallos o errores.
En una implementación, el campo de estado 3904 informa del estado de finalización del descriptor. El software debe inicializar este campo a 0 para poder detectar cuándo se ha escrito el registro de finalización.
TABLA T (códigos de estado del registro de finalización)
Figure imgf000057_0001
La tabla T anterior proporciona diversos códigos de estado y descripciones asociadas para una implementación.
La tabla U, a continuación, ilustra los códigos de fallo 3903 disponibles en una implementación que incluye un primer bit para indicar si la dirección de fallo fue una lectura o una escritura y un segundo bit para indicar si el acceso de fallo fue un acceso en modo usuario o en modo supervisor.
TABLA U (códigos de fallo del registro de finalización)
Figure imgf000058_0001
En una implementación, si este registro de finalización 3900 es para un descriptor que se envió como parte de un lote, el campo de índice 3902 contiene el índice en el lote del descriptor que generó este registro de finalización. Para un descriptor de lote, este campo puede ser 0xff. Para cualquier otro descriptor que no forme parte de un lote, este campo puede reservarse.
En una implementación, si la operación se completó parcialmente debido a un fallo de página, el campo bytes completados 3901 contiene el número de bytes de origen procesados antes de que se produjera el fallo. Todos los bytes de origen representados por este recuento se han procesado completamente y el resultado se ha escrito en la dirección de destino, según sea necesario de acuerdo con el tipo de operación. Para algunos tipos de operaciones, este campo también puede utilizarse cuando la operación se detiene antes de finalizar por alguna razón que no sea un fallo. Si la operación se ha completado totalmente, este campo puede establecerse a 0.
Para los tipos de operación en los que el tamaño de salida no es fácilmente determinable a partir de este valor, el registro de finalización también contiene el número de bytes escritos en la dirección de destino.
Si la operación se completó parcialmente debido a un fallo de página, este campo contiene la dirección que causó el fallo. Como regla general, todos los descriptores deben tener una dirección de registro de finalización 3804 válida y la bandera de dirección de registro de finalización válida debe ser 1. A continuación se describen algunas excepciones a esta regla.
En una implementación, el primer byte del registro de finalización es el byte de estado. Los valores de estado escritos por el dispositivo son todos distintos de cero. El software debe inicializar el campo de estado del registro de finalización a 0 antes de enviar el descriptor para poder saber cuándo el dispositivo ha escrito en el registro de finalización. La inicialización del registro de finalización también garantiza que está mapeado, por lo que el dispositivo no encontrará un fallo de página cuando acceda a él.
La bandera de solicitud de registro de finalización indica al dispositivo que debe escribir el registro de finalización aunque la operación se haya completado con éxito. Si esta bandera no está establecida, el dispositivo escribe el registro de finalización solo si hay un error.
La finalización del descriptor puede detectarse por el software usando cualquiera de los siguientes métodos:
1. Sondear el registro de finalización, esperando que el campo de estado sea distinto de cero.
2. Usar las instrucciones UMONITOR/UMWAIT (como se describe en el presente documento) en la dirección del registro de finalización, para bloquear hasta que se escriba o hasta que se agote el tiempo. El software debe comprobar entonces si el campo de estado es distinto de cero para determinar si la operación se ha completado.
3. Para los descriptores en modo de núcleo, solicitar una interrupción cuando la operación se haya completado.
4. Si el descriptor se encuentra en un lote, se establece la bandera de barrera en un descriptor posterior del mismo lote. La finalización del descriptor con la barrera o cualquier descriptor posterior en el mismo lote indica la finalización de todos los descriptores que preceden a la barrera.
5. Si el descriptor está en un lote, la finalización del descriptor de lote que lo inició indica la finalización de todos los descriptores del lote.
6. Emitir un descriptor de drenaje o un comando de drenaje y esperar a que se complete.
Si el estado de finalización indica una finalización parcial debido a un fallo de página, el registro de finalización indica cuánto procesamiento se completó (si lo hubo) antes de que se encontrara el fallo, y la dirección virtual donde se encontró el fallo. El software puede optar por arreglar el fallo (tocando la dirección del fallo desde el procesador) y volver a enviar el resto del trabajo en un nuevo descriptor o completar el resto del trabajo en el software. Los fallos en las direcciones de las listas de descriptores y de los registros de finalización se tratan de forma diferente y se describen con más detalle a continuación.
Una implementación del DSA solo soporta interrupciones con señalización de mensajes. DSA proporciona dos tipos de almacenamiento de mensajes de interrupción: (a) una tabla MSI-X, enumerada a través de la capacidad MSI-X, que almacena los mensajes de interrupción usados por el controlador del anfitrión; y (b) una tabla de almacenamiento de mensajes de interrupción (IMS) específicos de cada dispositivo, que almacena los mensajes de interrupción usados por los controladores invitados.
En una implementación, se pueden generar interrupciones para tres tipos de eventos: (1) finalización de un descriptor en modo de núcleo; (2) finalización de un comando de drenaje o aborto; y (3) un error publicado en el registro de errores de software o hardware. Para cada tipo de evento hay una activación de interrupción separada. Las interrupciones debidas a errores y a la finalización de los comandos abortar/drenar se generan utilizando la entrada 0 de la tabla MSI-X. El software puede leer el registro de causa de interrupción para determinar el motivo de la interrupción.
Para la finalización de un descriptor en modo de núcleo (por ejemplo, un descriptor en el que el campo U/S es 1), el mensaje de interrupción usado depende de cómo se envió el descriptor y de la bandera usar almacenamiento de mensajes de interrupción en el descriptor.
El mensaje de interrupción de finalización de un descriptor en modo de núcleo enviado a través de un portal con privilegios es generalmente una entrada en la tabla MSI-X, determinada por la dirección del portal. Sin embargo, si el campo soporte de almacenamiento de mensajes de interrupción en GENCAP es 1, un descriptor enviado a través de un portal con privilegios puede anular este comportamiento estableciendo la bandera de uso de almacenamiento de mensajes de interrupción en el descriptor. En este caso, el campo manejador de interrupción de finalización del descriptor se usa como índice en el almacenamiento de mensajes de interrupción.
El mensaje de interrupción de finalización para un descriptor en modo de núcleo enviado a través de un portal de invitado es una entrada en el almacenamiento de mensajes de interrupción, determinado por la dirección del portal.
Las interrupciones generadas por DSA se procesan a través del hardware de remapeo y publicación de interrupciones, tal y como lo configura el núcleo o el software de VMM.
Figure imgf000059_0001
Figure imgf000060_0001
TABLA V
Como se ha mencionado, el DSA soporta la emisión de varios descriptores a la vez. Un descriptor de lote contiene la dirección de una matriz de descriptores de trabajo en la memoria de anfitrión y el número de elementos de la matriz. El conjunto de descriptores de trabajo se llama "lote". El uso de descriptores por lotes permite a los clientes DSA enviar múltiples descriptores de trabajo usando una sola instrucción ENQCMD, ENQCMDS o MOVDIR64B y puede mejorar potencialmente el rendimiento general. DSA aplica un límite en el número de descriptores de trabajo en un lote. El límite se indica en el campo de tamaño máximo de lote del registro de capacidades generales.
Los descriptores de lotes se envían a las colas de trabajo de la misma manera que los demás descriptores de trabajo. Cuando el dispositivo procesa un descriptor de lote, el dispositivo lee la matriz de descriptores de trabajo de la memoria y a continuación procesa cada uno de los descriptores de trabajo. Los descriptores de trabajo no se procesan necesariamente en orden.
El PASID 3803 y la bandera U/S del descriptor de lote se usan para todos los descriptores del lote. Los campos PASID y U/S 3810 de los descriptores del lote se ignoran. Cada descriptor de trabajo en el lote puede especificar una dirección de registro de finalización 3804, al igual que con los descriptores de trabajo enviados directamente. Como alternativa, el descriptor de lote puede especificar una dirección de "cola de finalización" donde los registros de finalización de todos los descriptores de trabajo del lote se escriben por el dispositivo. En este caso, se ignoran los campos de dirección de registro de finalización 3804 en los descriptores del lote. La cola de finalización debe ser una entrada más grande que el recuento de descriptores, de modo que haya espacio para un registro de finalización para cada descriptor de lote más uno para el descriptor de lote. Los registros de finalización se generan en el orden en que se completan los descriptores, que puede no ser el mismo que el orden en que aparecen en la matriz de descriptores. Cada registro de finalización incluye el índice del descriptor en el lote que generó ese registro de finalización. Se usa un índice de 0xff para el propio descriptor de lote. Se usa un índice 0 para los descriptores enviados directamente que no sean descriptores de lote. Es posible que algunos descriptores del lote no generen registros de finalización, si no solicitan un registro de finalización y se completan con éxito. En este caso, el número de registros de finalización escritos en la cola de finalización puede ser menor que el número de descriptores del lote. El registro de finalización del descriptor de lote (si se solicita) se escribe en la cola de finalización después de los registros de finalización de todos los descriptores del lote.
Si el descriptor de lote no especifica una cola de finalización, el registro de finalización para el descriptor de lote (si se solicita) se escribe en su propia dirección de registro de finalización después de que se hayan completado todos los descriptores del lote. El registro de finalización del descriptor de lote contiene una indicación de si alguno de los descriptores del lote se ha completado con un estado no igual a éxito. Esto permite que el software solo mire el registro de finalización del descriptor de lote, en el caso habitual de que todos los descriptores del lote se hayan completado con éxito.
También puede solicitarse una interrupción de finalización por uno o más descriptores de trabajo en el lote, según sea necesario. El registro de finalización del descriptor de lote (si se solicita) se escribe después de los registros de finalización y las interrupciones de finalización de todos los descriptores del lote. La interrupción de finalización del descriptor de lote (si se solicita) se genera después del registro de finalización del descriptor de lote, al igual que con cualquier otro descriptor.
Un descriptor de lote no puede incluirse en un lote. No se soportan las matrices de descriptores anidadas o encadenadas.
Por defecto, DSA no garantiza ningún orden mientras se ejecutan los descriptores de trabajo. Los descriptores pueden enviarse y completados en cualquier orden que el dispositivo considere oportuno para maximizar el rendimiento. Por lo tanto, si es necesario el orden, el software debe pedirlo explícitamente; por ejemplo, el software puede enviar un descriptor, esperar el registro de finalización o la interrupción del descriptor para asegurar la finalización, y, a continuación, enviar el siguiente descriptor.
El software también puede especificar el orden de los descriptores en un lote especificado por un descriptor de lote. Cada descriptor de trabajo tiene una bandera de barrera. Cuando se establece, la barrera garantiza que el procesamiento de ese descriptor no se iniciará hasta que se completen los descriptores anteriores del mismo lote. Esto permite que un descriptor con barrera consuma los datos producidos por un descriptor anterior en el mismo lote.
Un descriptor se completa después de que todas las escrituras generadas por la operación sean globalmente observables; después de la lectura del destino, si se solicita; después de que la escritura en el registro de finalización sea observable globalmente, si es necesario; y después de la generación de la interrupción de finalización, si se solicita.
Si algún descriptor de un lote se completa con un estado que no es igual a éxito, por ejemplo, si se completa parcialmente debido a un fallo de página, se abandona un descriptor posterior con la bandera de barrera igual a 1 y los siguientes descriptores del lote. El registro de finalización del descriptor de lote que se usó para enviar el lote indica cuántos descriptores se completaron. Los descriptores que se completaron parcialmente y generaron un registro de finalización se cuentan como completados. Sólo los descriptores abandonados se consideran no completados.
La barrera también garantiza la ordenación de los registros de finalización y las interrupciones. Por ejemplo, un descriptor No-op con barrera y solicitud de interrupción de finalización configurados hará que la interrupción se genere después de que todos los descriptores precedentes en el lote se hayan completado (y sus registros de finalización se hayan escrito, si es necesario). Una escritura de registro de finalización siempre se ordena detrás de las escrituras de datos producidas por el mismo descriptor de trabajo y la interrupción de finalización (si se solicita) siempre se ordena detrás de la escritura de registro de finalización para el mismo descriptor de trabajo.
Drenaje es un descriptor que permite a un cliente esperar a que se completen todos los descriptores que pertenecen a su propio PASID. Se puede usar como una operación de barrera para todo el PASID. La operación de drenaje se completa cuando todos los descriptores anteriores con ese PASID se han completado. El descriptor de drenaje puede usarse por el software para solicitar un único registro de finalización o interrupción de la finalización de todos sus descriptores. Drenaje es un descriptor normal que se envía a la cola de trabajo normal. Un descriptor de drenaje no puede incluirse en un lote. (Se puede utilizar una bandera de barrera en un lote para esperar a que se completen los descriptores anteriores del lote)
El software debe garantizar que no se envíen descriptores con el PASID especificado al dispositivo después de que se envíe el descriptor de drenaje y antes de que se complete. Si se envían descriptores adicionales, no se especifica si la operación de drenaje también espera a que se completen los descriptores adicionales. Esto puede hacer que la operación de drenaje tarde mucho tiempo. Aunque el dispositivo no espere a que se completen los descriptores adicionales, es posible que algunos de ellos se completen antes de que finalice la operación de drenaje. En este sentido, drenaje es diferente de barrera, porque barrera garantiza que no se inicie ninguna operación posterior hasta que se hayan completado todas las operaciones anteriores.
En una implementación, los comandos de abortar/drenar se envían por software con privilegios (núcleo del SO o VMM) escribiendo en el registro abortar/drenar. Al recibir uno de estos comandos, el DSA espera a que se completen ciertos descriptores (descritos a continuación). Cuando el comando se completa, el software puede estar seguro de que no hay más descriptores de la categoría especificada pendientes en el dispositivo.
Hay tres tipos de comandos de drenaje en una implementación: Drenar todo, drenar PASID y drenar WQ. Cada comando tiene una bandera de abortar que indica al dispositivo que puede descartar cualquier descriptor pendiente en lugar de procesarlo hasta su finalización.
El comando drenar todo espera a que se completen todos los descriptores que se enviaron antes del comando drenar todo. Los descriptores enviados después del comando drenar todo pueden estar en curso en el momento en que se completa drenar todo. El dispositivo puede empezar a trabajar en nuevos descriptores mientras el comando drenar todo está esperando a que se completen los descriptores anteriores.
El comando drenar PASID espera todos los descriptores asociados con el PASID especificado. Cuando se completa el comando drenar PASID, no hay más descriptores para el PASID en el dispositivo. El software puede garantizar que no se envíen descriptores con el PASID especificado al dispositivo después de que se envíe el comando drenar PASID y antes de que se complete; de lo contrario el comportamiento es indefinido.
El comando drenar WQ espera todos los descriptores enviados a la cola de trabajo especificada. El software puede garantizar que no se envíen descriptores a la WQ después de que se envíe el comando drenar WQ y antes de que se complete.
Cuando se suspende una aplicación o VM que está utilizando DSA, puede tener descriptores pendientes enviados al DSA. Este trabajo debe completarse para que el cliente se encuentre en un estado coherente que pueda reanudarse más tarde. Los comandos drenar PASID y drenar todo se usan por el SO o VMM para esperar cualquier descriptor pendiente. El comando drenar PASID se usa para una aplicación o VM que estaba utilizando un único PASID. El comando drenar todo se usa para una VM que utiliza múltiples PASID.
Cuando se sale de una aplicación que usa DSA se termina por el sistema operativo (SO), el SO necesita garantizar de que no hay descriptores pendientes antes de poder liberar o reutilizar el espacio de direcciones, la memoria asignada y el PASID. Para borrar los descriptores pendientes, el SO usa el comando drenar PASID con el PASID del cliente que se está terminando y la bandera de abortar se establece a 1. Al recibir este comando, el DSA descarta todos los descriptores que pertenecen al PASID especificado sin procesarlos.
Una implementación del DSA proporciona un mecanismo para especificar la calidad del servicio para despachar el trabajo de múltiples WQ. El DSA permite que el software divida el espacio total de la WQ en múltiples WQ. A cada WQ se le puede asignar una prioridad diferente para despachar el trabajo. En una implementación, el planificador/árbitro de DSA 3513 despacha el trabajo de las WQ de manera que las WQ de mayor prioridad son atendidas más que las WQ de menor prioridad. Sin embargo, el DSA garantiza que las CMA de mayor prioridad no priven a las CMA de menor prioridad. Como se ha mencionado, se pueden emplear varios esquemas de priorización basándose en los requisitos de implementación.
En una implementación, la tabla de registro de configuración de WQ se usa para configurar las WQ. El software puede configurar el número de WQ activas para que coincida con el número de niveles de QoS deseados. El software configura cada WQ programando el tamaño de la WQ y algunos parámetros adicionales en la tabla de registro de configuración de la WQ. Esto, divide eficazmente todo el espacio de WQ en el número deseado de WQ. Las WQ no usadas tienen un tamaño de 0.
Los errores pueden dividirse a grandes rasgos en dos categorías; 1) Errores de afiliación, que se producen al procesar descriptores de PASID específicos, y 2) Errores de no afiliación, que son de naturaleza global y no específicos de PASID. EL DSA trata de evitar en lo posible que los errores de un PASID eliminen o afecten a otros PASID. Los errores específicos de PASID se notifican en el registro de finalización de los respectivos descriptores, excepto cuando el error está en el propio registro de finalización (por ejemplo, un fallo de página en la dirección del registro de finalización).
Un error en el envío del descriptor o en el registro de finalización de un descriptor puede notificarse al controlador del anfitrión a través del registro de errores del software (SWERROR). Un error de hardware puede notificarse a través del registro de errores de hardware (HWERROR).
Una implementación del DSA realiza las siguientes comprobaciones en el momento en que el bit de activación del registro de activación de dispositivo se establece a 1:
La activación del bus maestro es 1.
La combinación de las capacidades de PASID, ATS y PRS es válida. (Véase la tabla 6-3 en la sección 6.1.3.) La suma de los campos de tamaño de WQ de todos los registros WQCFG no es mayor que el tamaño de WQ total. Para cada registro GRPCFG, los campos WQ y motores son ambos 0 o ambos distintos de cero.
Cada WQ para la que el campo de tamaño en el registro WQCFG es distinto de cero está en un grupo.
Cada WQ para la que el campo de tamaño en el registro WQCFG es cero no está en ningún grupo.
Cada motor no está en más de un grupo.
Si alguna de estas comprobaciones falla, el dispositivo no se activa y el código de error se registra en el campo código de error del registro de activación del dispositivo. Estas comprobaciones pueden realizarse en cualquier orden. Por lo tanto, la indicación de un tipo de error no implica que no haya también otros errores. Los mismos errores de configuración pueden dar como resultado diferentes códigos de error en diferentes momentos o con diferentes versiones del dispositivo. Si ninguna de las comprobaciones falla, el dispositivo se activa y el campo activado se establece a 1.
El dispositivo realiza las siguientes comprobaciones en el momento en que el bit de activación de WQ de un registro WQCFG se establece a 1:
• El dispositivo está activado (es decir, el campo de activado del registro de activación de dispositivo es 1).
• El campo de tamaño de WQ es distinto de cero.
• El umbral de WQ no es mayor que el campo de tamaño de WQ.
• El campo de modo de WQ selecciona un modo soportado. Es decir, si el campo de soporte de modo compartido en WQCAP es 0, el modo de WQ es 1, o si el campo de soporte de modo especializado es WQCAP es 0, el modo de WQ es 0. Si los campos de soporte de modo compartido y soporte de modo especializado son 1, se permite cualquier valor de modo de WQ.
• Si el bit de soporte de bloqueo en caso de fallo en GENCAP es 0, el campo de activación de bloqueo en caso de fallo de WQ es 0.
Si alguna de estas comprobaciones falla, la WQ no se activa y el código de error se registra en el campo de código de error de WQ del registro de configuración de WQ 3500. Estas comprobaciones pueden realizarse en cualquier orden. Por lo tanto, la indicación de un tipo de error no implica que no haya también otros errores. Los mismos errores de configuración pueden dar como resultado diferentes códigos de error en diferentes momentos o con diferentes versiones del dispositivo. Si ninguna de las comprobaciones falla, el dispositivo se activa y el campo de WQ activada se establece a 1.
En una implementación, el DSA realiza las siguientes comprobaciones cuando se recibe un descriptor:
• La WQ identificada por la dirección de registro usada para enviar el descriptor es una WQ activa (el campo de tamaño del registro WQCFG es distinto de cero). Si esta comprobación falla, el error se registra en el registro de errores del software (SWERROR),
• Si el descriptor se envió a una WQ compartida,
• Se envió con ENQCMD o ENQCMDS. Si esta comprobación falla, el error se registra en SWERROR.
• Si el descriptor se envió a través de un portal sin privilegios o de invitado, la ocupación actual de la cola no es mayor que el umbral de WQ. Si esta comprobación falla, se devuelve una respuesta de reintento.
• Si el descriptor se envió a través de un portal con privilegios, la ocupación actual de la cola es inferior al tamaño de WQ. Si esta comprobación falla, se devuelve una respuesta de reintento.
• Si el descriptor se envió a una WQ especializada,
• Se envió con MOVDIR64B.
• La ocupación de la cola es menor que el tamaño de WQ.
Si cualquiera de estas comprobaciones falla, el error se registra en SWERROR.
En una implementación, el dispositivo realiza las siguientes comprobaciones en cada descriptor cuando se procesa:
• El valor en el campo de código de operación corresponde a una operación soportada. Esto incluye la comprobación de que la operación es válida en el contexto en el que se envió. Por ejemplo, un descriptor de lote dentro de un lote sería tratado como un código de operación no válido.
• No se establecen banderas reservadas. Esto incluye las banderas para las que el bit de capacidad correspondiente en el registro GENCAP es 0.
• No se establecen banderas no soportadas. Esto incluye banderas que están reservadas para su uso con ciertas operaciones. Por ejemplo, el bit de barrera se reserva en los descriptores que se ponen en cola directamente en lugar de como parte de un lote. También incluye banderas que están desactivadas en la configuración, tal como la bandera bloqueo en caso de fallo, que se reserva cuando el campo de activación de bloqueo en caso de fallo del registro WQCFG es 0.
• Se establecen las banderas requeridas. Por ejemplo, la bandera de solicitud de registro de finalización debe ser 1 en un descriptor para la operación de comparación.
• Los campos reservados son 0. Esto incluye cualquier campo que no tenga un significado definido para la operación especificada. Es posible que algunas implementaciones no comprueben todos los campos reservados, pero el software debe tener cuidado de borrar todos los campos no usados para lograr la máxima compatibilidad. En un descriptor de lote, el campo de recuento de descriptor no es mayor que el campo tamaño máximo de lote del registro GENCAP.
• El tamaño de transferencia, el tamaño del origen, el tamaño máximo del registro delta, el tamaño del registro delta y el tamaño máximo del destino (según corresponda al tipo de descriptor) no son mayores que el campo de tamaño máximo de la transferencia en el registro GENCAP.
• En una copia de memoria con descriptor de reparto doble, los bits 11:0 de las dos direcciones de destino son los mismos.
• Si la bandera de uso de almacenamiento de mensajes de interrupción está activada, el manejador de interrupción de finalización es menor que el tamaño de almacenamiento de mensajes de interrupción.
En una implementación, si la dirección de registro de finalización 3804 no puede traducirse, el descriptor 3800 se descarta y se registra un error en el registro de errores del software. De lo contrario, si alguna de estas comprobaciones falla, el registro de finalización se escribe con el campo de estado indicando el tipo de comprobación que ha fallado y los bytes completados establecidos 0. Se genera una interrupción de finalización, si se solicita.
Estas comprobaciones pueden realizarse en cualquier orden. Por lo tanto, la indicación de un tipo de error en el registro de finalización no implica que no haya también otros errores. El mismo descriptor inválido puede notificar diferentes códigos de error en diferentes momentos o con diferentes versiones del dispositivo.
Los campos reservados 3811 en los descriptores pueden ser de tres categorías: campos que siempre están reservados; campos que se reservan bajo algunas condiciones (por ejemplo, basándose en una capacidad, un campo de configuración, la forma en que se envió el descriptor o los valores de otros campos en el propio descriptor); y los campos que se reservan basándose en el tipo de operación. En las siguientes tablas se enumeran las condiciones en las que se reservan los campos.
TABLA W (Comprobación de campos reservados condicionales)
Figure imgf000064_0002
Figure imgf000064_0001
Figure imgf000065_0002
TABLA X (Comprobación de campos reservados específicos de la operación)
Operación Banderas permitidas Banderas reservadas1 Campos reservados
Figure imgf000065_0001
Inserción DIF Barrera Resultado de comprobación Bytes 38-39
Bloqueo en caso de fallo Byte 40 Relleno de la caché de destino Bytes 43-55 Sin sondeo de destino
Figure imgf000066_0001
Como se ha mencionado, DSA soporta el uso de direcciones físicas o virtuales. El uso de direcciones virtuales que se comparten con los procesos que se ejecutan en los núcleos del procesador se denomina memoria virtual compartida (SVM). Para soportar la SVM, el dispositivo proporciona un PASID cuando realiza traducciones de direcciones, y maneja los fallos de página que se producen cuando no hay traducción para una dirección. Sin embargo, el propio dispositivo no distingue entre direcciones virtuales y físicas; esta distinción está controlada por la programación de la IOMMU 1710.
En una implementación, DSA soporta las capacidades PCI Express del servicio de traducción de direcciones (ATS) y del servicio de solicitud de páginas (PRS), como se indica en la Figura 28, que muestra la lógica PCIe 2820 comunicándose con la lógica PCIe 2808 usando PCDI para aprovechar el ATS. ATS describe el comportamiento del dispositivo durante la traducción de direcciones. Cuando un descriptor entra en una unidad de procesamiento de descriptor, el dispositivo 2801 puede solicitar traducciones para las direcciones en el descriptor. Si hay una coincidencia en la TLB 2822 del dispositivo, el dispositivo usa la dirección física del anfitrión (HPA) correspondiente. Si hay un fallo de permiso o una falta, una implementación del DSA 2801 envía una solicitud de traducción de dirección a la IOMMU 2810 para la traducción (es decir, a través del enlace multiprotocolo 2800). La IOMMU 2810 puede a continuación ubicar la traducción recorriendo las respectivas tablas de páginas y devuelve una respuesta de traducción de direcciones que contiene la dirección traducida y los permisos efectivos. A continuación, el dispositivo 2801 almacena la traducción en la TLB de dispositivo 2822 y utiliza el HPA correspondiente para la operación. Si la IOMMU 2810 no puede ubicar la traducción en las tablas de páginas, puede devolver una respuesta de traducción de direcciones que indica que no hay traducción disponible. Cuando la respuesta de la IOMMU 2810 indica que no hay traducción o indica permisos efectivos que no incluyen el permiso requerido por la operación, se considera un fallo de página.
El dispositivo de DSA 2801 puede encontrar un fallo de página en uno de: 1) una dirección de registro de finalización 3804; 2) la dirección de la lista de descriptores en un descriptor de lote; o 3) una dirección de memoria intermedia de origen o de memoria intermedia de destino. El dispositivo de DSA 2801 puede bloquear hasta que se resuelva el fallo de página o completar prematuramente el descriptor y devolver una finalización parcial al cliente. En una implementación, el dispositivo de DSA 2801 siempre bloquea los fallos de página en las direcciones de registro de finalización 3804 y las direcciones de lista de descriptores.
Cuando el DSA se bloquea en un fallo de página, informa del fallo como una solicitud de servicios de solicitud de página (PRS) a la IOMMU 2810 para que sea atendida por el manejador de fallos de página del SO. La IOMMU 2810 puede notificar al SO a través de una interrupción. El SO valida la dirección y, si la comprobación es correcta, crea un mapeo en la tabla de páginas y devuelve una respuesta de PRS a través de la IOMMU 2810.
En una implementación, cada descriptor 3800 tiene una bandera de bloqueo en caso de fallo que indica si el DSA 2801 debe devolver una finalización parcial o un bloqueo cuando se produce un fallo de página en una dirección de memoria intermedia de origen o destino. Cuando la bandera de bloqueo en caso de fallo es 1, y se encuentra un fallo, el descriptor que encuentra el fallo se bloquea hasta que se recibe la respuesta de PRS. También pueden bloquearse otras operaciones detrás del descriptor con el fallo.
Cuando el fallo en caso de bloqueo es 0 y se encuentra un fallo de página en una dirección de memoria intermedia de origen o destino, el dispositivo detiene la operación y escribe el estado de finalización parcial junto con la dirección de fallo y la información de progreso en el registro de finalización. Cuando el software cliente recibe un registro de finalización que indica la finalización parcial, tiene la opción de arreglar el fallo en el procesador (tocando la página, por ejemplo) y enviar un nuevo descriptor de trabajo con el trabajo restante.
Como alternativa, el software puede completar el trabajo restante en el procesador. El campo de soporte de bloqueo en caso de fallo en el registro de capacidad general (GENCAP) puede indicar que el dispositivo soporta esta función, y el campo de activación de bloqueo en caso de fallo en el registro de configuración de cola de trabajo permite a la VMM o al controlador del núcleo controlar si las aplicaciones pueden usar la función.
Los fallos de la página del dispositivo pueden ser relativamente caros. De hecho, el coste de reparar los fallos de página del dispositivo puede ser mayor que el coste de reparar los fallos de página del procesador. Incluso si el dispositivo realiza una finalización parcial del trabajo en lugar de un bloqueo en caso de fallo, sigue incurriendo en sobrecargas porque requiere la intervención del software para reparar el fallo de la página y volver a enviar el trabajo. Por lo tanto, para obtener el mejor rendimiento, es deseable que el software minimice los fallos de página del dispositivo sin incurrir en las sobrecargas de anclaje y desanclaje.
Las listas de descriptores de lotes y las memorias intermedias de datos de origen suelen ser producidos por el software, justo antes de enviarlos al dispositivo. Por lo tanto, no es probable que estas direcciones incurran en fallos debido a la localidad temporal. Los descriptores de finalización y las memorias intermedias de datos de destino, sin embargo, son más propensos a incurrir en fallos si no son tocados por el software antes de enviarlos al dispositivo. Estos fallos pueden minimizarse si el software "toca en escritura" explícitamente estas páginas antes de enviarlas.
Durante una solicitud de invalidación de la TLB del dispositivo, si la dirección que se está invalidando se está usando en una unidad de procesamiento de descriptores, el dispositivo espera a que el motor haya terminado con la dirección antes de completar la solicitud de invalidación.
Tipos de descriptores adicionales
Algunas implementaciones pueden usar uno o más de los siguientes tipos de descriptores adicionales:
No-op
La Figura 40 ilustra un descriptor de no-op 4000 ilustrativo y un registro de finalización de no-op 4001. La operación No-op 4005 no realiza ninguna operación de DMA. Puede solicitar un registro de finalización y/o una interrupción de finalización. Si está en un lote, puede especificar la bandera de barrera para garantizar que la finalización del descriptor No-op se produzca después de la finalización de todos los descriptores anteriores del lote.
Lote
La Figura 41 ilustra un descriptor de lote 4100 ilustrativo y un registro de finalización de no-op 4101. La operación de lote 4108 pone en cola varios descriptores a la vez. La dirección de la lista de descriptores 4102 es la dirección de una matriz contigua de descriptores de trabajo a procesar. En una implementación, cada descriptor de la matriz tiene 64 bytes. La dirección de la lista de descriptores 4102 está alineada a 64 bytes. El recuento de descriptores 4103 es el número de descriptores en la matriz. El conjunto de descriptores de la matriz se denomina "lote". El número máximo de descriptores permitidos en un lote se proporciona en el campo de tamaño máximo del lote en GENCAP.
El PASID 4104 y la bandera U/S 4105 en el descriptor de lote se usan para todos los descriptores del lote. Los campos PASID 4104 y la bandera U/S 4105 de los descriptores del lote se ignoran. Si la bandera de activación de la cola de finalización en el descriptor de lote 4100 está activada, la bandera de dirección de finalización válida debe ser 1 y el campo de dirección de cola de finalización 4106 contiene la dirección de una cola de finalización que se usa para todos los descriptores del lote. En este caso, se ignoran los campos de dirección de registro de finalización 4106 en los descriptores del lote. Si el campo de soporte de cola de finalización en el registro de capacidad general es 0, la bandera de activación de cola de finalización está reservada.
Si la bandera de activación de la cola de finalización en el descriptor de lote es 0, el registro de finalización de cada descriptor de lote se escribe en la dirección de registro de finalización 4106 de cada descriptor. En este caso, si la bandera de solicitud de registro de finalización es 1 en el descriptor de lote, el campo de dirección de cola de finalización se usa como dirección de registro de finalización 4106 únicamente para el descriptor de lote.
El campo de estado 4110 del registro de finalización de lote 4101 indica éxito si todos los descriptores del lote se completaron con éxito; de lo contrario, indica que uno o más descriptores se han completado con un estado que no es igual a éxito. El campo de descriptores completados 4111 del registro de finalización contiene el número total de descriptores del lote que se han procesado, tanto si han tenido éxito como si no. Los descriptores completados 4111 pueden ser menores que el recuento de descriptores 4103 si hay una barrera en el lote o si se ha producido un fallo de página durante la lectura del lote.
Drenaje
La Figura 42 ilustra un descriptor de drenaje 4200 ilustrativo y un registro de finalización de drenaje 4201. La operación de drenaje 4208 espera a que se completen todos los descriptores pendientes en la cola de trabajo a la que se somete el descriptor de drenaje 4200 que están asociados con el PASID 4202. Este descriptor puede usarse durante el apagado normal por un proceso que ha estado utilizando el dispositivo. Para esperar todos los descriptores asociados con el PASID 4202, el software debe enviar una operación de drenaje por separado a cada cola de trabajo con la que se utilizó el PASID 4202. El software debe garantizar que no se presenten descriptores con el PASID 4202 especificado a la cola de trabajo después de que se presente el descriptor de drenaje 4201 y antes de que se complete.
Un descriptor de drenaje 4201 no puede incluirse en un lote; se trata como un tipo de operación no soportada. El drenaje debe especificar la solicitud de registro de finalización o la solicitud de interrupción de finalización. La notificación de finalización se realiza después de que los otros descriptores hayan finalizado.
Movimiento de la memoria
La Figura 43 ilustra un descriptor de movimiento de memoria 4300 ilustrativo y un registro de finalización de movimiento de memoria 4301. La operación de movimiento de memoria 4308 copia la memoria desde la dirección de origen 4302 a la dirección de destino 4303. El número de bytes copiados viene dado por el tamaño de transferencia 4304. No hay requisitos de alineación para las direcciones de memoria o el tamaño de transferencia. Si las regiones de origen y destino se superponen, la copia de memoria se realiza como si toda la memoria intermedia de origen se copiara en el espacio temporal y a continuación se copiara en la memoria intermedia de destino. Esto puede implementarse invirtiendo la dirección de la copia cuando el principio de la memoria intermedia de destino se superpone al final de la memoria intermedia de origen.
Si la operación se completa parcialmente debido a un fallo de página, el campo de dirección 4310 del registro de finalización es 0 si la copia se realizó empezando por el principio de las memorias intermedias de origen y destino, y el campo de dirección es 1 si la dirección de la copia se invirtió.
Para reanudar la operación después de una finalización parcial, si la dirección es 0, los campos de dirección de origen y de destino 4302-4303 del descriptor de continuación deben incrementarse en bytes completados, y el tamaño de transferencia debe reducirse en bytes completados 4311. Si la dirección es 1, el tamaño de transferencia 4304 debe disminuir en bytes completados 4311, pero los campos de dirección de origen y de destino 4302-4303 deben ser los mismos que en el descriptor original. Obsérvese que si se produce una finalización parcial posterior, el campo de dirección 4310 puede no ser el mismo que el de la primera finalización parcial.
Relleno
La Figura 44 ilustra un descriptor de llenado ilustrativo 4400. La operación de llenado de memoria 4408 llena la memoria en la dirección de destino 4406 con el valor del campo de patrón 4405. El tamaño del patrón puede ser de 8 bytes. Para usar un patrón más pequeño, el software debe replicar el patrón en el descriptor. El número de bytes escritos viene dado por el tamaño de transferencia 4407. No es necesario que el tamaño de transferencia sea un múltiplo del tamaño del patrón. No hay requisitos de alineación para la dirección de destino o el tamaño de transferencia. Si la operación se completa parcialmente debido a un fallo de página, el campo de bytes completados del registro de finalización contiene el número de bytes escritos en el destino antes de que se produzca el fallo.
Comparación
La Figura 45 ilustra un descriptor de comparación 4500 ilustrativo y un registro de finalización de comparación 4501. La operación de comparación 4508 compara la memoria en la dirección de origen1 4504 con la memoria en la dirección de origen24505. El número de bytes comparados viene dado por el tamaño de transferencia 4506. No hay requisitos de alineación para las direcciones de memoria o el tamaño de transferencia 4506. Las banderas de dirección de registro de finalización válida y de solicitud de registro de finalización deben ser 1 y la dirección de registro de finalización debe ser válida. El resultado de la comparación se escribe en el campo de resultado 4510 del registro de finalización 4501: un valor de 0 indica que las dos regiones de memoria coinciden, y un valor de 1 indica que no coinciden. Si el resultado 4510 es 1, el campo de bytes completados 4511 del registro de finalización indica el desplazamiento de bytes de la primera diferencia. Si la operación se completa parcialmente debido a un fallo de página, el resultado es 0. Si se hubiera detectado una diferencia, se notificaría la diferencia en lugar del fallo de la página.
Si la operación se realiza con éxito y la bandera de comprobación de resultado es 1, el campo de estado 4512 del registro de finalización se establece de acuerdo con el resultado y el resultado esperado, como se muestra en la siguiente tabla. Esto permite que un descriptor posterior en el mismo lote con la bandera de barrera continúe o detenga la ejecución del lote basándose en el resultado de la comparación.
TABLA Y
Figure imgf000069_0001
Comparación inmediata
La Figura 46 ilustra un descriptor inmediato de comparación ilustrativo 4600. La operación de comparación inmediata 4608 compara la memoria en la dirección de origen 4601 con el valor del campo de patrón 4602. El tamaño del patrón es de 8 bytes. Para usar un patrón más pequeño, el software debe replicar el patrón en el descriptor. El número de bytes comparados viene dado por el tamaño de transferencia 4603. No es necesario que el tamaño de transferencia sea un múltiplo del tamaño del patrón. Las banderas de dirección de registro de finalización válida y de solicitud de registro de finalización deben ser 1 y la dirección de registro de finalización 4604 debe ser válida. El resultado de la comparación se escribe en el campo de resultado del registro de finalización: un valor de 0 indica que la región de memoria coincide con el patrón, y un valor de 1 indica que no coincide. Si el resultado es 1, el campo de bytes completados del registro de finalización indica la ubicación de la primera diferencia. Puede que no sea la ubicación exacta del byte, pero se garantiza que no sea mayor que la primera diferencia. Si la operación se completa parcialmente debido a un fallo de página, el resultado es 0. Si se hubiera detectado una diferencia, se notificaría la diferencia en lugar del fallo de la página. En una implementación, el formato del registro de finalización para la comparación inmediata y el comportamiento de resultado de comprobación y resultado esperado son idénticos a los de la comparación.
Crear un registro delta
La Figura 47 ilustra un descriptor de crear registro de datos 4700 ilustrativo y registro de crear finalización de registro delta 4701. La operación crear registro delta 4708 compara la memoria en la dirección origen1 4705 con la memoria en la dirección de origen2 4702 y genera un registro delta que contiene la información necesaria para actualizar el origen1 para que coincida con el origen2. El número de bytes comparados viene dado por el tamaño de transferencia 4703. El tamaño de transferencia está limitado por el desplazamiento máximo que se puede almacenar en el registro delta, como se describe a continuación. No hay requisitos de alineación para las direcciones de memoria o el tamaño de transferencia. Las banderas de dirección de registro de finalización válida y de solicitud de registro de finalización deben ser 1 y la dirección de registro de finalización 4704 debe ser válida.
El tamaño máximo del registro delta viene dado por el tamaño máximo del registro delta 4709. El tamaño máximo del registro delta 4709 debe ser un múltiplo del tamaño delta (10 bytes) y no debe ser mayor que el tamaño máximo de transferencia en GENCAP. El tamaño real del registro delta depende del número de diferencias detectadas entre el origen1 y el origen2; se escribe en el campo de tamaño de registro delta 4710 del registro de finalización. Si el espacio necesario en el registro delta supera el tamaño máximo del registro delta 4709 especificado en el descriptor, la operación se completa con un registro delta parcial.
El resultado de la comparación se escribe en el campo de resultado 4711 del registro de finalización 4701. Si las dos regiones coinciden exactamente, entonces el resultado es 0, el tamaño del registro delta es 0 y los bytes completados son 0. Si las dos regiones no coinciden y se ha escrito un conjunto completo de deltas en el registro delta, entonces el resultado es 1, el tamaño del registro delta contiene el tamaño total de todas las diferencias encontradas y los bytes completados son 0. Si las dos regiones no coinciden, y el espacio necesario para registrar todos los deltas excede el tamaño máximo del registro delta, entonces el resultado es 2, el tamaño del registro delta 4710 contiene el tamaño del conjunto de deltas escrito en el registro delta (típicamente igual o casi igual al tamaño del registro delta especificado en el descriptor), y los bytes completados 4712 contienen el número de bytes comparados antes de que se exceda el espacio en el registro delta.
Si la operación se completa parcialmente debido a un fallo de página, entonces el resultado 4711 es 0 o 1, como se ha descrito en el párrafo anterior, los bytes completados 4712 contienen el número de bytes comparados antes de que se produzca el fallo de página, y el tamaño del registro delta contiene el espacio utilizado en el registro delta antes de que se produzca el fallo de página.
El formato del registro delta se muestra en la Figura 48. El registro delta contiene una matriz de deltas. Cada delta contiene un desplazamiento de 2 bytes 4801 y un bloque de datos de 8 bytes 4802 del origen2 que es diferente de los 8 bytes correspondientes del origen1. El tamaño total del registro delta es un múltiplo de 10. Dado que el desplazamiento 4801 es un campo de 16 bits que representa un múltiplo de 8 bytes, el desplazamiento máximo que se puede expresar es 0x7FFF8, por lo que el tamaño máximo de transferencia es 0x80000 bytes (512 KB).
Si la operación se realiza con éxito y la bandera de comprobar resultado es 1, el campo estado del registro de finalización se establece de acuerdo con el resultado y el resultado esperado, como se muestra en la tabla siguiente. Esto permite que un descriptor posterior en el mismo lote con la bandera de barrera continúe o detenga la ejecución del lote basándose en el resultado de la creación del registro delta. Los bits 7:2 del resultado esperado se ignoran.
TABLA Z
Figure imgf000070_0001
Aplicar el registro delta
La Figura 49 ilustra un descriptor de registro delta de aplicación ilustrativo 4901. La operación de aplicación de registro delta 4902 aplica un registro delta al contenido de la memoria en la dirección de destino 4903. La dirección del registro delta 4904 es la dirección de un registro delta que fue creado por una operación de creación de registro delta 4902 que se completó con un resultado igual a 1. El tamaño del registro delta 4905 es el tamaño del registro delta, tal como se indica en el registro de finalización de la operación de creación de registro delta 4902. La dirección de destino 4903 es la dirección de una memoria intermedia que contiene el mismo contenido que la memoria en la dirección de origen1 cuando se creó el registro delta. El tamaño de transferencia 4906 es el mismo que el tamaño de transferencia usado cuando se creó el registro delta. Una vez completada la operación de aplicar registro delta 4902, la memoria de la dirección de destino 4903 coincidirá con el contenido que había en la memoria de la dirección de origen2 cuando se creó el registro delta. No hay requisitos de alineación para las direcciones de memoria o el tamaño de transferencia.
Si se encuentra un fallo de página durante la operación de aplicar registro delta 4902, el campo de bytes completados del registro de finalización contiene el número de bytes del registro delta que se aplicaron con éxito al destino. Si el software decide enviar otro descriptor para reanudar la operación, el descriptor de continuación debe contener la misma dirección de destino 4903 que el original. La dirección del registro delta 4904 debe incrementarse en bytes completados (para que apunte al primer delta no aplicado), y el tamaño del registro delta 4905 debe reducirse en bytes completados.
La Figura 50 muestra una implementación del uso de las operaciones de crear registro delta y aplicar registro delta. En primer lugar, se realiza la operación de creación de registro delta 5001. Lee las dos memorias intermedias de origen -Orígenes 1 y 2- y escribe el registro delta 5010, registrando el tamaño real del registro delta 5004 en su registro de finalización 5003. La operación de aplicar registro delta 5005 toma el contenido del registro delta que fue escrito por la operación de crear registro delta 5001, junto con su tamaño y una copia de los datos de origenl, y actualiza la memoria intermedia de destino 5015 para que sea un duplicado de la memoria intermedia de origen2 original. La operación de crear un registro delta incluye un tamaño máximo de registro delta 5002.
Copia de la memoria con doble reparto
La Figura 51 ilustra una copia de memoria ilustrativa con un descriptor de reparto doble 5100 y una copia de memoria con un registro de finalización de reparto doble 5102. La operación de copia de memoria con doble reparto 5104 copia la memoria de la dirección de origen 5105 a la dirección de destino1 5106 y a la dirección de destino25107. El número de bytes copiados viene dado por el tamaño de transferencia 5108. No hay requisitos de alineación para la dirección de origen o el tamaño de transferencia. Los bits 11:0 de las dos direcciones de destino 5106-5107 deben ser iguales.
Si la región de origen se solapa con cualquiera de las regiones de destino, la copia de memoria se realiza como si toda la memoria intermedia de origen se copiara en el espacio temporal y a continuación se copiara en las memorias intermedias de destino. Esto puede implementarse invirtiendo la dirección de la copia cuando el principio de una memoria intermedia de destino se superpone al final de la memoria intermedia de origen. Si la región de origen se solapa con las dos regiones de destino o si las dos regiones de destino se solapan, es un error. Si la operación se completa parcialmente debido a un fallo de página, la operación de copia se detiene después de haber escrito el mismo número de bytes en ambas regiones de destino y el campo de dirección 5110 del registro de finalización es 0 si la copia se realizó empezando por el principio de las memorias intermedias de origen y destino, y el campo de dirección es 1 si la dirección de la copia se invirtió.
Para reanudar la operación después de una finalización parcial, si la dirección 5110 es 0, los campos de dirección de origen 5105 y de destino 5106-5107 del descriptor de continuación deben incrementarse en bytes completados 5111, y el tamaño de transferencia 5108 debe reducirse en bytes completados 5111. Si la dirección es 1, el tamaño de transferencia 5108 debe disminuir en bytes completados 5111, pero los campos de dirección de origen 5105 y de destino 5106-5107 deben ser los mismos que en el descriptor original. Obsérvese que si se produce una finalización parcial posterior, el campo de dirección 5110 puede no ser el mismo que el de la primera finalización parcial.
Generación de comprobación de redundancia cíclica (CRC)
La Figura 52 ilustra un descriptor de generación de CRC ilustrativo 5200 y un registro de finalización de generación de CRC 5201. La operación de generación de CRC 5204 calcula la CRC en la memoria en la dirección de origen. El número de bytes usados para el cálculo de la CRC viene dado por el tamaño de transferencia 5205. No hay requisitos de alineación para las direcciones de memoria o el tamaño de transferencia 5205. Las banderas de dirección de registro de finalización válida y de solicitud de registro de finalización deben ser 1 y la dirección de registro de finalización 5206 debe ser válida. El valor de CRC calculado se escribe en el registro de finalización.
Si la operación se completa parcialmente debido a un fallo de página, el resultado de CRC parcial se escribe en el registro de finalización junto con la información de fallo de página. Si el software corrige el fallo y reanuda la operación, debe copiar este resultado parcial en el campo de semilla de CRC del descriptor de continuación. De lo contrario, el campo de semilla de CRC debe ser 0.
Copia con generación de CRC
La Figura 53 ilustra una copia ilustrativa con descriptor de generación de CRC 5300. La operación de copia con generación de CRC 5305 copia la memoria de la dirección de origen 5302 a la dirección de destino 5303 y calcula la CRC sobre los datos copiados. El número de bytes copiados viene dado por el tamaño de transferencia 5304. No hay requisitos de alineación para las direcciones de memoria o el tamaño de transferencia. Si las regiones de origen y destino se superponen, es un error. Las banderas de dirección de registro de finalización válida y de solicitud de registro de finalización deben ser 1 y la dirección de registro de finalización debe ser válida. El valor de CRC calculado se escribe en el registro de finalización.
Si la operación se completa parcialmente debido a un fallo de página, el resultado de CRC parcial se escribe en el registro de finalización junto con la información de fallo de página. Si el software corrige el fallo y reanuda la operación, debe copiar este resultado parcial en el campo de semilla de CRC del descriptor de continuación. De lo contrario, el campo de semilla de CRC debe ser 0. En una implementación, el formato del registro de finalización para la copia con generación de CRC es el mismo que el formato para la generación de CRC.
Inserción de campo de integridad de datos (DIF)
La Figura 54 ilustra un descriptor de inserción DIF 5400 ilustrativo y un registro de finalización de inserción DIF 5401. La operación de inserción DIF 5405 copia la memoria desde la dirección de origen 5402 a la dirección de destino 5403, calcula el campo de integridad de datos (DIF) en los datos de origen e inserta el DIF en los datos de salida. El número de bytes de origen copiados viene dado por el tamaño de transferencia 5406. El cálculo del DIF se realiza en cada bloque de datos de origen que tenga, por ejemplo, 512, 520, 4096 o 4104 bytes. El tamaño de transferencia debe ser un múltiplo del tamaño del bloque de origen. El número de bytes escritos en el destino es el tamaño de transferencia más 8 bytes por cada bloque de origen. No hay ningún requisito de alineación para las direcciones de memoria. Si las regiones de origen y destino se superponen, es un error. Si la operación se completa parcialmente debido a un fallo de página, los valores actualizados de la etiqueta de referencia y la etiqueta de aplicación se escriben en el registro de finalización junto con la información de fallo de página. Si el software corrige el fallo y reanuda la operación, puede copiar estos campos en el descriptor de continuación.
Eliminación de DIF
La Figura 55 ilustra un descriptor de eliminación DIF 5500 ilustrativo y un registro de finalización de eliminación DIF 5501. La operación de eliminación de DIF 5505 copia la memoria de la dirección de origen 5502 a la dirección de destino 5503, calcula el campo de integridad de datos (DIF) en los datos de origen y compara el DIF calculado con el DIF contenido en los datos. El número de bytes de origen leídos viene dado por el tamaño de transferencia 5506. El cálculo del DIF se realiza en cada bloque de datos de origen que puede ser de 512, 520, 4096 o 4104 bytes. El tamaño de transferencia debe ser un múltiplo del tamaño del bloque de origen más 8 bytes por cada bloque de origen. El número de bytes escritos en el destino es el tamaño de transferencia menos 8 bytes por cada bloque de origen. No hay ningún requisito de alineación para las direcciones de memoria. Si las regiones de origen y destino se superponen, es un error. Si la operación se completa parcialmente debido a un fallo de página, los valores actualizados de la etiqueta de referencia y la etiqueta de aplicación se escriben en el registro de finalización junto con la información de fallo de página. Si el software corrige el fallo y reanuda la operación, puede copiar estos campos en el descriptor de continuación.
Actualización de DIF
La Figura 56 ilustra un descriptor de actualización DIF 5600 ilustrativo y un registro de finalización de actualización DIF 5601. La operación de movimiento de memoria con actualización de DIF 5605 copia la memoria desde la dirección de origen 5602 a la dirección de destino 5603, calcula el campo de integridad de datos (DIF) en los datos de origen y compara el DIF calculado con el DIF contenido en los datos. Calcula simultáneamente el DIF en los datos de origen usando los campos DIF de destino en el descriptor e inserta el DIF calculado en los datos de salida. El número de bytes de origen leídos viene dado por el tamaño de transferencia 5606. El cálculo del DIF se realiza en cada bloque de datos de origen que puede ser de 512, 520, 4096 o 4104 bytes. El tamaño de transferencia 5606 debe ser un múltiplo del tamaño del bloque de origen más 8 bytes por cada bloque de origen. El número de bytes escritos en el destino es el mismo que el tamaño de transferencia 5606. No hay ningún requisito de alineación para las direcciones de memoria. Si las regiones de origen y destino se superponen, es un error. Si la operación se completa parcialmente debido a un fallo de página, los valores actualizados de las etiquetas de referencia y aplicación de origen y destino se escriben en el registro de finalización junto con la información de fallo de página. Si el software corrige el fallo y reanuda la operación, puede copiar estos campos en el descriptor de continuación.
La tabla AA a continuación ilustra las banderas DIF usadas en una implementación. La tabla BB ilustra las banderas DIF de origen usadas en una implementación, y la tabla CC ilustra las banderas DIF de destino en una implementación.
TABLA AA (banderas DIF)
Figure imgf000072_0001
Banderas DIF de origen
TABLA BB (Banderas DIF de origen)
Figure imgf000072_0002
Figure imgf000073_0001
Banderas DIF de destino
TABLA CC (Banderas DIF de destino)
Figure imgf000073_0002
Figure imgf000074_0001
En una implementación, un campo de Resultado DIF informa del estado de una operación DIF. Este campo solo puede definirse para las operaciones de eliminación de DIF y actualización de DIF y solo si el campo de estado del registro de finalización es éxito o éxito con predicado falso. La tabla DD a continuación ilustra ejemplos de códigos de campos de resultados de DIF.
TABLA DD (códigos del campo de resultado de DIF)
Figure imgf000074_0002
La condición de detectar F se detecta cuando una de las siguientes situaciones mostradas en la Tabla EE es verdadera:
TABLA EE
Figure imgf000075_0001
Si la operación se realiza con éxito y la bandera de Comprobar Resultado es 1, el campo Estado del registro de finalización se establece de acuerdo con el resultado de DIF, como se muestra en la Tabla FF a continuación. Esto permite que un descriptor posterior en el mismo lote con la bandera de barrera continúe o detenga la ejecución del lote basándose en el resultado de la operación.
TABLA FF
Figure imgf000075_0002
Descarga de la caché
La Figura 57 ilustra un descriptor de descarga de caché ilustrativo 5700. La operación de descarga de caché 5705 descarga las cachés del procesador en la dirección de destino. El número de bytes que se descargan viene dado por el tamaño de transferencia 5702. No es necesario que el tamaño de la transferencia sea un múltiplo del tamaño de la línea de caché. No hay requisitos de alineación para la dirección de destino o el tamaño de transferencia. Cualquier línea de caché que esté parcialmente cubierta por la región de destino se descarga.
Si la bandera de llenado de caché de destino es 0, las líneas de caché afectadas pueden ser invalidadas desde todos los niveles de la jerarquía de caché. Si una línea de caché contiene datos modificados en cualquier nivel de la jerarquía de caché, los datos se escriben de nuevo en la memoria. Esto es similar al comportamiento de la instrucción CLFLUSH implementada en algunos procesadores.
Si la bandera de llenado de caché de destino es 1, las líneas de caché modificadas se escriben en la memoria principal, pero no se desalojan de las cachés. Esto es similar al comportamiento de la instrucción CLWB en algunos procesadores.
El término aceleradores se utiliza en ocasiones en el presente documento para referirse a agentes poco acoplados que pueden usarse por el software que se ejecuta en los procesadores del anfitrión para descargar o realizar cualquier tipo de tarea de computación o E/S. Dependiendo del tipo de acelerador y del modelo de uso, podría tratarse de tareas que realizan el movimiento de datos a la memoria o al almacenamiento, el cálculo, la comunicación o cualquier combinación de estas.
La expresión "acoplado de manera flexible" se refiere a la forma en que estos aceleradores son expuestos y accedidos por el software anfitrión. En concreto, no se exponen como extensiones ISA del procesador y, en su lugar, se exponen como dispositivos de punto terminal enumerables PCI-Express en la plataforma. El acoplamiento flexible permite a estos agentes aceptar solicitudes de trabajo del software anfitrión y operar de forma asíncrona al procesador anfitrión.
Los "aceleradores" pueden ser agentes programables (tales como una GPU/GPGPU), agentes de función fija (tales como motores de compresión o criptografía) o agentes reconfigurables, como una matriz de puertas programables en campo (FPGA). Algunas de estos pueden usarse para la descarga de cálculos, mientras que otros (tales como RDMA o interfaces de tejido de anfitrión) pueden usarse para el procesamiento de paquetes, la comunicación, el almacenamiento o las operaciones de paso de mensajes.
Los dispositivos aceleradores pueden estar integrados físicamente a diferentes niveles que incluyen en la pastilla (es decir, la misma pastilla que el procesador), en el paquete, en el conjunto de chips o en la placa base; o pueden ser dispositivos discretos conectados a PCIe. En el caso de los aceleradores integrados, aunque se enumeran como dispositivos finales PCI-Express, algunos de estos aceleradores pueden estar conectados de forma coherente (en el tejido coherente en la pastilla o en interfaces coherentes externas), mientras que otros pueden estar conectados a interfaces internas no coherentes o a una interfaz PCI-Express externa.
A nivel conceptual, un "acelerador" y un controlador de dispositivo de E/S de alto rendimiento son similares. Lo que los distingue son capacidades tales como la memoria virtual unificada/compartida, la capacidad de operar en memoria paginable, el envío de trabajo en modo usuario, la planificación de tareas/preferencia y el soporte para la sincronización de baja latencia. Como tales, los aceleradores pueden considerarse una nueva y mejorada categoría de dispositivos de E/S de alto rendimiento.
MODELOS DE PROCESAMIENTO DE DESCARGA
Los modelos de procesamiento de la descarga del acelerador pueden clasificarse a grandes rasgos en tres categorías de uso:
1. Envío por flujo continuo: En el modelo de descarga de envío por flujo continuo, las pequeñas unidades de trabajo se transmiten a gran velocidad al acelerador. Un ejemplo típico de este uso es un plano de datos de red que realiza diversos tipos de procesamiento de paquetes a altas velocidades.
2. Baja latencia: Para algunos usos de la descarga, la latencia de la operación de descarga (tanto en el despacho de la tarea al acelerador como la actuación del acelerador sobre ella) es crítica. Un ejemplo de este uso son las construcciones de paso de mensajes de baja latencia que incluyen operaciones remotas de obtención, colocación y atómicas a través de un tejido de anfitrión.
3. Escalable: La descarga escalable se refiere a los usos en los que los servicios de un acelerador informático son directamente (por ejemplo, desde el anillo más alto del dominio de protección jerárquico, tal como el anillo 3) accesibles a un gran número (ilimitado) de aplicaciones cliente (dentro y a través de máquinas virtuales), sin restricciones impuestas por el dispositivo acelerador, tal como el número de colas de trabajo o el número de timbres soportados en el dispositivo. Varios de los dispositivos aceleradores y de las interconexiones de los procesadores descritos en el presente documento entran en esta categoría. Tal escalabilidad se aplica a los dispositivos de descarga de cómputo que soportan la compartición de tiempo/planificación del trabajo, tal como los aceleradores de GPU, GPGPU, FPGA o de compresión, o los usos de paso de mensajes, tal como en el caso de las bases de datos empresariales con grandes requisitos de escalabilidad para la operación sin bloqueo.
DESPACHO DE TRABAJO A TRAVÉS DE LOS MODELOS DE DESCARGA
Cada uno de estos modelos de procesamiento de descarga impone sus propios retos de despacho de trabajo, como se describe a continuación.
1. Despacho de trabajo para usos de descarga de envío por flujo continuo
Para los usos de envío por flujo continuo, un modelo típico de despacho de trabajo es utilizar colas de trabajo residentes en memoria. En concreto, el dispositivo tiene configurada la ubicación y el tamaño de la cola de trabajo en la memoria. El hardware implementa un registro de timbre (puntero de cola) que es actualizado por el software cuando se añaden nuevos elementos de trabajo a la cola de trabajo. El hardware informa del puntero de la cabecera actual para que el software aplique el control de flujo productor-consumidor en los elementos de la cola de trabajo. Para los usos de envío por flujo continuo, el modelo típico es que el software compruebe si hay espacio en la cola de trabajo consultando el puntero de la cabecera (a menudo mantenido en la memoria del anfitrión por el hardware para evitar las sobrecargas de las lecturas UC MMIO por parte del software) y el puntero de la cola almacenado en caché en el software, y añadir nuevos elementos de trabajo a la cola de trabajo residente en la memoria y actualizar el puntero de la cola usando una escritura de registro de timbre en el dispositivo.
La escritura del timbre es típicamente una escritura no almacenable en caché (UC) de 4 u 8 bytes en MMIO. En algunos procesadores, la escritura UC es una operación serializada que asegura que los almacenes más antiguos sean observados globalmente antes de emitir la escritura UC (necesaria para los usos de productor-consumidor), pero también bloquea todos los almacenes más recientes en la canalización del procesador para que no sean emitidos hasta que la escritura UC sea publicada por la plataforma. La latencia típica de una operación de escritura en UC en un procesador de servidor Xeon es del orden de 80-100 ns, tiempo durante el cual todas las operaciones de almacenamiento más recientes son bloqueadas por el núcleo, limitando el rendimiento de la descarga de envío por flujo continuo.
Mientras que un enfoque para abordar la serialización de los almacenes más recientes después de una escritura de timbre UC es usar una operación de almacenamiento de combinación de escritura (WC) para la escritura de timbre (debido a la ordenación débil de WC), el uso de los almacenamientos WC para las escrituras de timbre impone algunos desafíos: El tamaño de escritura del timbre (normalmente DWORD o QWORD) es menor que el tamaño de la línea de caché. Estas escrituras parciales incurren en una latencia adicional debido a que el procesador las mantiene en sus memorias intermedias de combinación de escritura (WCB) para una potencial oportunidad de escritura, incurriendo en una latencia para que la escritura del timbre sea emitida desde el procesador. El software puede obligar a que se emitan a través de la barrera explícita del almacén, incurriendo en la misma serialización para los almacenes más recientes que con el timbre UC.
Otro problema con la MMIO mapeado en WC es la exposición de las lecturas especulativas y previstas de forma incorrecta (con MOVNTDQA) a la MMIO mapeada en WC (con registros que pueden tener efectos secundarios de lectura). Tratar esto es engorroso para los dispositivos, ya que requeriría que los dispositivos alojen los registros de timbre mapeados por WC en páginas separadas que el resto de los registros MMIO mapeados por UC. Esto también impone desafíos en los usos virtualizados, donde el software VMM ya no puede ignorar el tipo de memoria de invitado y forzar el mapeo UC para cualquier dispositivo MMIO expuesto al invitado usando tablas de páginas EPT.
La instrucción MOVDIRI descrita en el presente documento trata las limitaciones anteriores con el uso de almacenes UC o WC para las escrituras de timbre con estos usos de descarga de envío por flujo continuo.
2. Despacho de trabajo para usos de descarga de baja latencia
Algunos tipos de dispositivos aceleradores están altamente optimizados para completar la operación solicitada con una latencia mínima. A diferencia de los aceleradores de envío por flujo continuo (que están optimizados para el rendimiento), estos aceleradores suelen implementar colas de trabajo alojadas en el dispositivo (expuestas a través de MMIO del dispositivo) para evitar las latencias de lectura DMA para obtener elementos de trabajo (y en algunos casos incluso memorias intermedias de datos) de las colas de trabajo alojadas en la memoria. En su lugar, el software anfitrión envía el trabajo escribiendo directamente los descriptores de trabajo (y en algunos casos también los datos) a las colas de trabajo alojadas en el dispositivo y expuestas a través de la MMIO del dispositivo. Algunos ejemplos de tales dispositivos son los controladores de tejido de anfitrión, los dispositivos DMA remotos (RDMA) y los nuevos controladores de almacenamiento, tales como la memoria no volátil (NVM)-Express. El uso de la cola de trabajo alojada en el dispositivo presenta pocos problemas con una ISA existente.
Para evitar la sobrecarga de serialización de las escrituras UC, las direcciones MMIO de las colas de trabajo alojadas en el dispositivo se suelen mapear como WC. Esto expone los mismos desafíos que con los timbres mapeados por WC para los aceleradores de envío por flujo continuo.
Además, el uso de los almacenamientos WC a las colas de trabajo alojadas en el dispositivo requiere que los dispositivos se protejan contra el comportamiento de la atomicidad de escritura de algunos procesadores. Por ejemplo, algunos procesadores solo garantizan la atomicidad de las operaciones de escritura hasta las escrituras de 8 bytes dentro de un límite de la línea de caché (y para las operaciones de bloqueo (LOCK)) y no definen ninguna atomicidad de finalización de escritura garantizada. La atomicidad de las operaciones de escritura es la granularidad en la que una operación de almacenamiento del procesador es observada por otros agentes, y es una propiedad de la arquitectura del conjunto de instrucciones del procesador y de los protocolos de coherencia. La atomicidad de la finalización de la escritura es la granularidad en la que una operación de almacenamiento no almacenable en caché es observada por el receptor (controlador de memoria en el caso de la memoria, o dispositivo en el caso de MMIO). La atomicidad de la finalización de la escritura es más fuerte que la atomicidad de la operación de escritura, y es una función no solo de la arquitectura del conjunto de instrucciones del procesador, sino también de la plataforma. Sin la atomicidad de la finalización de la escritura, una instrucción del procesador que realiza una operación de almacenamiento no almacenable en caché de N bytes puede recibirse como múltiples transacciones de escritura (en conflicto) por la cola de trabajo alojada en el dispositivo. En la actualidad, el hardware del dispositivo tiene que protegerse contra estas escrituras en conflicto mediante el seguimiento de cada palabra del descriptor de trabajo o de los datos escritos en la cola de trabajo alojada en el dispositivo.
La instrucción MOVDIR64B descrita en el presente documento aborda las limitaciones anteriores al soportar escrituras de 64 bytes con atomicidad garantizada de finalización de escritura de 64 bytes. MOVDIR64B también es útil para otros usos, tales como las escrituras en memoria persistente (NVM conectada al controlador de memoria) y la replicación de datos entre sistemas a través de puentes no transparentes (NTB).
3. Despacho de trabajo para usos de descarga escalable
El enfoque tradicional para enviar trabajo a los dispositivos de E/S desde las aplicaciones implica hacer llamadas al sistema a la pila de E/S del núcleo que enruta la solicitud a través de los controladores de dispositivos del núcleo al dispositivo controlador de E/S. Aunque este enfoque es escalable (cualquier número de aplicaciones puede compartir los servicios del dispositivo), incurre en la latencia y la sobrecarga de una pila de E/S del núcleo serializada, que suele ser un cuello de botella de rendimiento para los dispositivos y aceleradores de alto rendimiento.
Para soportar el despacho de trabajo de baja carga, algunos dispositivos de alto rendimiento soportan el acceso directo al anillo 3 para permitir el despacho directo de trabajo al dispositivo y para comprobar la finalización del trabajo. En este modelo, algunos recursos del dispositivo (timbre, cola de trabajo, cola de finalización, etc.) se asignan y mapean al espacio de direcciones virtual de la aplicación. Una vez mapeado, el software del anillo 3 (por ejemplo, un controlador o biblioteca en modo usuario) puede despachar directamente el trabajo al acelerador. Para los dispositivos que soportan la capacidad de memoria virtual compartida (SVM), el timbre y las colas de trabajo se configuran por el controlador en modo de núcleo para identificar el identificador del espacio de direcciones del proceso (PASID) del proceso de aplicación al que se mapea el timbre y la cola de trabajo. Cuando se procesa un elemento de trabajo despachado a través de una cola de trabajo particular, el dispositivo usa el respectivo PASID configurado para esa cola de trabajo para las traducciones de direcciones virtuales a físicas a través de la unidad de gestión de memoria de E/S (IOMMU).
Uno de los retos del envío directo de trabajos en anillo 3 es la cuestión de la escalabilidad. El número de clientes de la aplicación que pueden enviar trabajo directamente a un dispositivo acelerador depende del número de colas/timbres (o colas de trabajo alojadas en el dispositivo) que soporta el dispositivo acelerador. Esto se debe a que un timbre o una cola de trabajo alojada en un dispositivo se asigna/mapea estáticamente a un cliente de aplicación, y hay un número fijo de estos recursos soportados por el diseño del dispositivo acelerador. Algunos dispositivos aceleradores intentan "sortear" este problema de escalabilidad comprometiendo en exceso los recursos de timbre que tienen (separando y volviendo a conectar dinámicamente los timbres a petición de una aplicación), pero suelen ser engorrosos y difíciles de escalar. Con los dispositivos que soportan la virtualización de E/S (tal como la virtualización de E/S de raíz única (SR-IOV)), los recursos de timbre/cola de trabajo limitados se ven aún más restringidos, ya que deben repartirse entre diferentes funciones virtuales (VF) asignadas a diferentes máquinas virtuales.
El problema del escalado es más crítico para los aceleradores de paso de mensajes de alto rendimiento (soportando algunos de los dispositivos RDMA de 64K a 1 M pares de colas) usados por aplicaciones empresariales tales como las bases de datos para una operación sin bloqueos, y para los aceleradores de cálculo que soportan el uso compartido de los recursos del acelerador entre las tareas enviadas por un gran número de clientes.
Las instrucciones ENQCMD/S descritas en el presente documento abordan las limitaciones de escalado mencionadas anteriormente para permitir que un número ilimitado de clientes se suscriban y compartan recursos de cola de trabajo en un acelerador.
Una implementación incluye nuevos tipos de operaciones de almacenamientos por los núcleos del procesador, que incluyen los almacenes directos y los almacenamientos en cola.
En una implementación, los almacenes directos se generan por las instrucciones MOVDIRI y MOVDIR64B descritas en el presente documento.
Capacidad de almacenamiento en caché: Al igual que los almacenes UC y WC, los almacenes directos no son almacenables en caché. Si se emite un almacén directo a una dirección que está en la caché, la línea se escribe de nuevo (si se modifica) y se invalida de la caché, antes del almacén directo.
Ordenación de la memoria: Al igual que los almacenamientos WC, los almacenes directos están débilmente ordenados. En concreto, no se ordenan contra los almacenes WB/WC/NT más antiguos, CLFLUSHOPT y CLWB a direcciones diferentes. Los almacenes WB/WC/NT más recientes, CLFLUSHOPT o CLWB a diferentes direcciones pueden pasar a los almacenes directos más antiguos. Los almacenes directos a la misma dirección se ordenan siempre con los almacenes más antiguos (que incluyen almacenes directos) a la misma dirección. Los almacenes directos tienen barrera por cualquier operación que aplique la barrera de almacenes (por ejemplo, SFENCE, MFENCE, almacenes UC/WP/WT, LOCK, instrucciones de En TrA dA/SALIDA, etc.).
Combinación de escritura: Los almacenes directos tienen un comportamiento de combinación de escritura diferente al de los almacenes WC normales. Específicamente, los almacenes directos son elegibles para el desalojo inmediato de la memoria intermedia de escritura y, por lo tanto, no se combinan con los almacenes más recientes (que incluyen los almacenes directos) a la misma dirección. Los almacenes WC/NT más antiguos mantenidos en las memorias intermedias de combinación de escritura pueden combinarse con los almacenes directos más recientes a la misma dirección, y los usos que necesiten evitar dicha combinación deben almacenar explícitamente los almacenamientos WC/NT en barrera antes de ejecutar los almacenes directos a la misma dirección.
Atomicidad: Los almacenes directos soportan la atomicidad de finalización de escritura para el tamaño de escritura de la instrucción que emite el almacén directo. En el caso de MOVDIRI, cuando el destino está alineado a 4 bytes (o a 8 bytes) la atomicidad de finalización de escritura es de 4 bytes (o de 8 bytes). En el caso de MOVDIR64B, el destino debe estar alineado a 64 bytes y la atomicidad de la escritura es de 64 bytes. La atomicidad en la finalización de la escritura garantiza que los almacenes directos no se dividan en múltiples transacciones de escritura al ser procesados por el controlador de memoria o el complejo raíz. Las implementaciones del complejo raíz en los procesadores que soportan los almacenes directos garantizan que los almacenes directos se reenvíen en el tejido PCI-Express externo (y en los tejidos de E/S internos dentro del SoC que sigue la ordenación PCI-Express) como una única transacción de escritura publicada no en conflicto. Una operación de lectura desde cualquier agente (procesador o agente no procesador) a una ubicación de memoria verá todos o ninguno de los datos escritos por una instrucción que emita una operación de almacén directo.
Ignorar el tipo de memoria de destino: Los almacenes directos ignoran el tipo de memoria de la dirección de destino (incluyendo los tipos UC/WP) y siempre siguen un orden débil. Esto permite al software mapear la MMIO del dispositivo como UC, y acceder a registros específicos (tales como timbre o registros de cola de trabajo alojados en el dispositivo) usando instrucciones de almacén directo (MOVDIRI o MOVDIR64B), mientras se sigue accediendo a otros registros que pueden tener un requisito de serialización estricto utilizando operaciones MOV normales que siguen el orden de UC según el tipo de memoria UC mapeado. Esto también permite que las instrucciones de almacén directo operen desde el software de invitado, mientras que el software de monitorización de la máquina virtual (VMM) (que no tiene conocimientos específicos del dispositivo) asigna la MMIO expuesta por el invitado como UC en las tablas de páginas extendidas (EPT) del procesador, ignorando el tipo de memoria de invitado.
Los SoC que soportan los almacenes directos necesitan asegurar la atomicidad de finalización de escritura para los almacenes directos de la siguiente manera:
Almacenes directos a la memoria principal: Para los almacenes directos a la memoria principal, el tejido coherente y el agente del sistema deben garantizar que todos los bytes de datos de un almacén directo se emitan al agente de origen o a otro punto de capacidad de observación global (GO) para las solicitudes a la memoria como una única transacción de escritura (no en conflicto). Para las plataformas que soportan la memoria persistente, los agentes de inicio, los controladores de memoria, las cachés de memoria secundaria, los motores de encriptación de memoria en línea, los buses de memoria (tales como DDR-T) que conectan la memoria persistente y los propios controladores de memoria persistente deben soportar la misma o mayor granularidad de atomicidad de finalización de escritura para los almacenes directos. Por tanto, el software puede realizar un almacén directo de 64 bytes usando MOVDIR64B a la memoria (volátil o persistente), y tener la garantía de que los 64 bytes de escritura serán procesados atómicamente por todos los agentes. Al igual que con las escrituras normales en la memoria persistente, si el software necesita comprometerse explícitamente con la persistencia, el software sigue la secuencia de almacén directo con barrera/confirmar/barrera.
Almacenes directos a la E/S mapeada en memoria: Para los almacenes directos a la E/S mapeada en memoria (MMIO), el tejido coherente y el agente del sistema deben garantizar que todos los bytes de datos de un almacén directo se emitan al complejo raíz (punto de capacidad de observación global para las solicitudes a MMIO) como una única transacción de escritura (no en conflicto). Las implementaciones del complejo raíz deben garantizar que cada almacén directo se procese y reenvíe como una única transacción de escritura publicada (no en conflicto) en los tejidos de E/S internos que conectan los puntos finales integrados del complejo raíz PCI-Express (RCIEP) y los puertos raíz (RP). Los puertos raíz PCI-Express y los puertos de conmutación deben reenviar cada almacén directo como una única transacción de escritura publicada. La atomicidad en la finalización de la escritura no está definida ni garantizada para los almacenes directos dirigidos a dispositivos en o detrás de puentes secundarios (tales como los puentes PCI, PCI-X heredados) o buses secundarios (tales como USB, LPC, etc.).
Obsérvese que algunas implementaciones de SoC ya garantizan la atomicidad de la finalización de la escritura para las solicitudes de escritura de WC. En concreto, las escrituras WC de línea parcial (WCiL) y las escrituras WC de línea completa (WCiLF) ya son procesadas con atomicidad de finalización de escritura por el agente del sistema, los controladores de memoria, el complejo raíz y los tejidos de E/S. En este tipo de implementaciones, no es necesario que el procesador distinga las escrituras directas de las escrituras WC, y la diferencia de comportamiento entre los almacenes directos y los almacenamientos WC es interna al núcleo del procesador. Por lo tanto, no se proponen cambios en las especificaciones del tejido interno o externo para las escrituras directas.
El manejo de una escritura directa recibida por un punto final PCI-Express o RCIEP es específico de la implementación del dispositivo. Dependiendo de la interfaz de programación del dispositivo, el dispositivo y su controlador pueden requerir que algunos de sus registros (por ejemplo, los registros de timbre o los registros de cola de trabajo alojados en el dispositivo) se escriban siempre usando instrucciones de almacén directo (tales como MOVDIR64B) y se procesen atómicamente dentro del dispositivo. Las escrituras en otros registros del dispositivo pueden ser procesadas por el dispositivo sin ninguna consideración o expectativa de atomicidad. En el caso de los RCIEP, si se implementa un registro con requisito de atomicidad de escritura para el acceso a través de interfaces de banda secundaria o cableado privado, dichas implementaciones deben garantizar la propiedad de atomicidad de escritura a través de medios específicos de implementación.
Los almacenes de cola en una implementación se generan por las instrucciones ENQCMD y ENQCMDS descritas en el presente documento. El objetivo previsto de un almacén de cola es una cola de trabajo compartida (SWQ) en un dispositivo acelerador. En una implementación, los almacenes de cola tienen las siguientes propiedades.
No publicado: Los almacenes de cola generan una transacción de escritura no publicada de 64 bytes a la dirección de destino, y reciben una respuesta de finalización que indica el estado de éxito o de reintento. El estado éxito/reintento devuelto en la respuesta de finalización puede ser devuelto al software por la instrucción ENQCMD/S (por ejemplo, en la bandera cero).
Capacidad de almacenamiento en caché: En una implementación, los almacenes de cola no son almacenables en caché. Las plataformas que soportan los almacenes de cola obligan a que las escrituras no publicadas de cola se dirijan solo a rangos de direcciones (MMIO) que estén explícitamente activados para aceptar estos almacenes.
Ordenación de la memoria: Los almacenes de cola pueden actualizar el estado de la arquitectura (por ejemplo, la bandera cero) con el estado de finalización de la escritura no publicada. Por lo tanto, un procesador lógico puede tener como máximo un almacén de cola. En este sentido, un almacén de cola de un procesador lógico no puede pasar a otro almacén de cola emitido desde el mismo procesador lógico. Los almacenes de cola no se ordenan contra los almacenes WB/WC/NT más antiguos, CLFLUSHOPT o CLWB a diferentes direcciones. El software que necesite aplicar tal ordenamiento puede usar una barrera de almacenes explícito después de tales almacenes y antes del almacén de cola. Los almacenes de cola se ordenan siempre con los almacenes más antiguos a la misma dirección.
Alineación: Las instrucciones ENQCMD/S obligan a que la dirección de destino de almacén de cola esté alineada a 64 bytes.
Atomicidad: Los almacenes de cola generados por las instrucciones ENQCMD/S soportan la atomicidad de finalización de escritura de 64 bytes. La atomicidad de la finalización de la escritura garantiza que los almacenes de cola no se dividen en múltiples transacciones al ser procesados por el complejo raíz. Las implementaciones del complejo raíz en los procesadores que soportan los almacenes de cola garantizan que cada almacén de cola se reenvía como una única transacción de escritura de 64 bytes no publicada al dispositivo final.
Ignorar el tipo de memoria de destino: Al igual que los almacenes directos, los almacenes de cola ignoran el tipo de memoria de la dirección de destino (incluyendo los tipos UC/WP) y siempre siguen el orden descrito anteriormente. Esto permite que el software continúe mapeando el dispositivo MMIO como UC, y acceda a los registros de la cola de trabajo compartida (SWQ) usando instrucciones ENQCMD/S, mientras continúa accediendo a otros registros utilizando instrucciones MOV normales o a través de instrucciones de almacén directo (MOVDIRI o MOVDIR64B). Esto también permite que las instrucciones de almacén de cola operen desde el software invitado, mientras que el software VMM (que no tiene conocimiento específico del dispositivo) mapea la MMIO expuesta al invitado como UC en las tablas de páginas extendidas (EPT) del procesador, ignorando el tipo de memoria de invitado.
Consideraciones sobre la plataforma para los almacenes de cola
En algunas implementaciones, un conjunto específico de dispositivos integrados en la plataforma soporta la capacidad de cola de trabajo compartida (SWQ). Estos dispositivos pueden conectarse al complejo raíz a través de tejidos de E/S internos. Estos dispositivos pueden exponerse al software de invitado como puntos finales integrados en el complejo de la raíz PCI Express (RCIEP) o como dispositivos finales PCI Express detrás de los puertos raíz virtuales (VRP).
Las plataformas que soportan dispositivos integrados con SWQ deben limitar el enrutamiento de las solicitudes de escritura no publicadas de cola en los tejidos de E/S internos solo a dichos dispositivos. Esto es para asegurar que el nuevo tipo de transacción (escritura no publicada de cola) no sea tratado como un paquete de capa de transacción (TLP) malformado por un dispositivo final no consciente de la cola.
Los almacenes de cola a todas las demás direcciones (incluyendo los rangos de direcciones de memoria principal y todos los demás rangos de direcciones mapeados en memoria) son terminados por la plataforma y se devuelve una respuesta normal (no de error) al procesador emisor con el estado de finalización de reintento. No se generan errores de plataforma en tales terminaciones de almacén de cola, ya que el software sin privilegios (software de anillo 3, o software de anillo 0 en modo VMX no de raíz) puede generar las transacciones de escritura no publicadas de colas ejecutando las instrucciones ENQCMD/S.
Las implementaciones del complejo raíz deben asegurarse de que los almacenes de cola se procesen y reenvíen como transacciones de escritura únicas (no en conflicto) no publicadas en tejidos de E/S internos a los dispositivos integrados que soportan las SWQ.
Consideraciones sobre el rendimiento de la plataforma
Esta sección describe algunas de las consideraciones de rendimiento en el procesamiento de los almacenes de cola por el agente de sistema y los agentes de sistema.
Ordenamiento relajado para la asignación de entradas del rastreador de agente del sistema (TOR) para los almacenes de cola:
Para mantener la consistencia de la memoria, las implementaciones del agente de sistema suelen aplicar un orden estricto para las peticiones a una dirección de línea de caché (cuando se asignan entradas de TOR) para la memoria coherente y MMIO. Aunque esto es necesario para soportar el ordenamiento total de los accesos de memoria coherentes, este ordenamiento estricto para los almacenes de cola impone un problema de rendimiento. Esto se debe a que los almacenes de cola se dirigen a las colas de trabajo compartidas (SWQ) en los dispositivos y, por lo tanto, será común tener solicitudes de almacén de cola emitidas desde múltiples procesadores lógicos con la misma dirección SWQ de destino. Además, a diferencia de los almacenes normales que se publican en el agente del sistema, los almacenes de cola no se publican e incurren en una latencia similar a la de las lecturas. Para evitar la condición de permitir solo un almacén de cola pendiente a una cola de trabajo compartida, se requiere que las implementaciones del agente del sistema relajen el orden estricto para las solicitudes de almacén de cola a la misma dirección, y en su lugar permitan asignaciones de TOR para múltiples almacenes de cola al vuelo a la misma dirección. Dado que un procesador lógico solo puede emitir como máximo un almacén de cola a la vez, el agente del sistema/plataforma puede tratar cada almacén de cola de forma independiente sin problemas de orden.
Soporte de múltiples escrituras pendientes de cola no publicadas en agentes de puente de E/S:
Las implementaciones de puentes de E/S suelen limitar el número de peticiones no publicadas (de lectura) que soporta la ruta aguas abajo a un número reducido (a menudo a una sola petición). Esto se debe a que las lecturas del procesador a MMIO (que son en su mayoría lecturas de UC) no son críticas para el rendimiento en la mayoría de los usos, y a que el soporte de una gran profundidad de cola para las lecturas requiere memorias intermedias para los datos devueltos, lo que aumenta el coste del hardware. Dado que se espera que los almacenes de cola se usen normalmente para el despacho de trabajo a los dispositivos aceleradores, la aplicación de esta cola limitada para las escrituras no publicadas de cola puede ser perjudicial para el rendimiento. Se recomienda que las implementaciones de puentes de E/S soporten un aumento de la profundidad de la cola (alguna proporción práctica del número de procesadores lógicos, ya que un procesador lógico solo puede tener una solicitud pendiente de almacén de cola a la vez) para mejorar el ancho de banda de escritura no publicada de cola. A diferencia de las solicitudes de lectura, los almacenes en cola no incurren en el coste de hardware de las memorias intermedias de datos, ya que las finalizaciones de escritura no publicadas en cola solo devuelven un estado de finalización (éxito frente a reintento) y ningún dato.
Soporte del canal virtual con las escrituras no publicadas de cola
A diferencia de las típicas peticiones de lectura y escritura en memoria en los buses de E/S que tienen requisitos de ordenación productor-consumidor (tales como los especificados por la ordenación de transacciones PCI-Express), las escrituras no publicadas de cola no tienen ningún requisito de ordenación en el bus de E/S. Esto permite el uso de un canal virtual no VCO para emitir escrituras de cola no publicadas y devolver las respectivas terminaciones. La ventaja de usar un canal no VCO es que las terminaciones de escritura no publicadas de cola pueden tener una mejor latencia (menos ciclos para retener el núcleo) al evitar ser ordenadas detrás de las escrituras publicadas aguas arriba en VC0 desde el dispositivo al anfitrión. Se recomienda que las implementaciones consideren cuidadosamente los usos de los dispositivos integrados y minimicen la latencia de finalización de la cola no publicada.
Terminación intermedia de la escritura no publicada de cola
Para manejar el control de flujo específico en situaciones de alta latencia (tales como la gestión de la energía para reactivar un enlace interno, o en un flujo de bloqueo), un agente intermedio (agente del sistema, puente de E/S, etc.) puede abandonar una solicitud legítima de almacén de cola y devolver una respuesta de finalización con reintento al núcleo emisor. El software que emite el almacén de cola no tiene visibilidad directa si la respuesta de reintento fue de un agente intermedio o del objetivo, y normalmente reintentaría (potencialmente con algún retroceso) en el software.
Las implementaciones que realizan tal terminación intermedia deben tener un cuidado extremo para asegurarse de que dicho comportamiento no puede exponer ningún ataque de denegación de servicio a través de los clientes de software que comparten una SWQ.
Soporte de la cola de trabajo compartida en los dispositivos finales
La Figura 34 ilustra el concepto de una cola de trabajo compartida (SWQ), que permite a múltiples agentes de software no cooperantes (aplicaciones 3410-3412) enviar trabajo a través de una cola de trabajo compartida 3401, utilizando las instrucciones ENQCMD/S descritas en el presente documento.
Las siguientes consideraciones son aplicables a los dispositivos finales que implementan colas de trabajo compartidas (SWQ).
SWQ y su enumeración: Una función física del dispositivo (PF) puede soportar una o más SWQ. Cada SWQ es accesible para las escrituras no publicadas de cola a través de un registro alineado y dimensionado de 64 bytes (denominado en este punto como SWQ_REG) en el rango de direcciones MMIO del dispositivo. Se recomienda que cada uno de estos SWQ_REG en un dispositivo esté ubicado en una única región de tamaño de página del sistema (4KB). El controlador del dispositivo es responsable de informar/enumerar la capacidad de SWQ, el número de SWQ soportadas y las correspondientes direcciones SWQ_REG al software a través de las interfaces de software apropiadas. El controlador también puede informar opcionalmente de la profundidad de la SWQ soportada para el ajuste del software o con fines informativos (aunque esto no es necesario para la corrección funcional). Para los dispositivos que soportan múltiples funciones físicas, se recomienda soportar SWQ independientes para cada función física.
Soporte de SWQ en dispositivos de virtualización de E/S de raíz única (SR-IOV): Los dispositivos que soportan SR-IOV pueden soportar SWQ independientes para cada función virtual (VF), expuestos a través de SWQ_REG en los respectivos registros de dirección base (BAR) de VF. Este punto de diseño permite el máximo aislamiento del rendimiento para el envío de trabajo a través de las VF, y puede ser apropiado para un número pequeño o moderado de VF. En el caso de los dispositivos que soportan un gran número de VF (en los que no es práctico una SWQ independiente por VF), una única SWQ puede compartirse por varias VF. Incluso en este caso, cada VF tiene sus propios SWQ_REG privados en sus BAR de VF, excepto que están respaldados por una SWQ común a través de las VF que comparten la SWQ. Para estos diseños de dispositivos, las VF que comparten una SWQ pueden decidirse estáticamente por el diseño de hardware, o el mapeo entre una instancia de SWQ_REG de una VF dada puede ser dinámicamente configurado/descontinuado a través de la función física y su controlador. Los diseños de dispositivos que comparten SWQ a través de VF necesitan prestar especial atención a la QoS y a la protección contra ataques de denegación de servicio como se describe más adelante en esta sección. Cuando se comparten SWQ entre VF, se debe tener cuidado en el diseño del dispositivo para identificar qué VF recibió una solicitud de cola aceptada a SWQ. Al despachar las solicitudes de trabajo desde la SWQ, el dispositivo debe asegurarse de que las solicitudes aguas arriba estén debidamente etiquetadas con el ID del solicitante (bus/dispositivo/función n.°) de la respectiva VF (además del PASID que se transmitió en la carga útil de la solicitud de cola).
Dirección de escritura no publicada en cola: Los dispositivos finales que soportan SWQ están obligados a aceptar escrituras no publicadas en cola a cualquier dirección enrutada a través de sus BAR de memoria de PF o VF. Para cualquier solicitud de escritura no publicada de cola recibida por un dispositivo final a una dirección que no es una dirección SWQ_REG, el dispositivo puede ser requerido para no tratar esto como un error (por ejemplo, TLP malformado, etc.) y en su lugar devolver la finalización con un estado de finalización de reintento (MRS). Esto puede hacerse para garantizar que el uso de instrucciones ENQCMD/S por el software no privilegiado (invitado de VMX de anillo 3 o anillo 0) para emitir erróneamente o maliciosamente almacenes de cola a direcciones que no son SWQ_REG en un dispositivo con capacidad de SWQ no pueda dar como resultado una notificación de error no fatal o fatal con consecuencias de manejo de error específicas de la plataforma.
Manejo de solicitud no de cola a los REG de SWQ: Los dispositivos finales que soportan SWQ pueden dejar caer silenciosamente las solicitudes no de cola (escrituras y lecturas de memoria normales) a las direcciones SWQ_REG sin tratarlas como errores fatales o no fatales. Las solicitudes de lectura a las direcciones SWQ_REG pueden devolver una respuesta de finalización exitosa (a diferencia de UR o CA) con un valor de todo 1 para los bytes de datos solicitados. Las solicitudes de escritura en memoria normal (publicadas) a las direcciones SWQ_REG simplemente se descartan sin que el dispositivo final actúe. Esto puede hacerse para garantizar que el software sin privilegios no pueda generar solicitudes normales de lectura y escritura a la dirección SWQ_REG para causar erróneamente o maliciosamente notificaciones de errores no fatales o fatales con consecuencias de manejo de errores específicos de la plataforma.
Profundidad y almacenamiento de la cola de SWQ: La profundidad y el almacenamiento de la cola de SWQ son específicos de la implementación del dispositivo. Los diseños de los dispositivos deben garantizar que se soporte una profundidad de cola suficiente para que la SWQ logre la máxima utilización del dispositivo. El almacenamiento para la SWQ puede implementarse en el dispositivo. Los dispositivos integrados en el SoC pueden utilizar la memoria principal robada (memoria privada no visible para el SO y reservada para el uso del dispositivo) como memoria intermedia de derrame para la SWQ, lo que permite mayores profundidades de cola de la SWQ que las posibles con el almacenamiento en el dispositivo. En este tipo de diseños, el uso de una memoria intermedia de derrame es transparente para el software, ya que el hardware del dispositivo decide cuándo derramar (en lugar de abandonar la solicitud de cola y enviar un estado de finalización de reintento), obtener de la memoria intermedia de derrame para la ejecución de comandos y mantener cualquier requisito de orden específico de los comandos. A todos los efectos, este uso de la memoria intermedia de derrame es equivalente a un dispositivo discreto que utiliza la DRAM local conectada al dispositivo para el almacenamiento de SWQ. Los diseños de dispositivos con una memoria intermedia de derrame en la memoria robada deben tener un cuidado extremo para garantizar que dicha memoria robada está protegida de cualquier acceso que no sea la lectura y escritura de la memoria intermedia de derrame por el dispositivo para el que está asignada.
Comportamiento de SWQ sin bloqueo: Por razones de rendimiento, las implementaciones de los dispositivos deben responder rápidamente a las solicitudes de escritura no publicadas en cola con el estado de finalización de éxito o reintento, y no bloquear las finalizaciones de cola para que se libere la capacidad de SWQ para aceptar la solicitud. La decisión de aceptar o rechazar una solicitud de cola a la SWQ podría basarse en la capacidad, la QoS/ocupación o cualquier otra política. A continuación, se describen algunos ejemplos de consideraciones de QoS.
Consideraciones sobre la QoS de SWQ: Para una escritura no publicada en cola dirigida a una dirección SWQ_REG, el dispositivo final puede aplicar el control de admisión para decidir si acepta la solicitud a la SWQ respectiva (y envía un estado de finalización correcto) o la abandona (y envía un estado de finalización de reintento). El control de admisión puede ser específico del dispositivo y del uso, y las políticas específicas soportadas/impuestas por el hardware pueden ser expuestas al software a través de las interfaces del controlador de la función física (PF). Dado que la SWQ es un recurso compartido con múltiples clientes productores, las implementaciones de los dispositivos deben garantizar una protección adecuada contra los ataques de denegación de servicio entre productores. La QoS para la SWQ se refiere únicamente a la aceptación de solicitudes de trabajo (a través de solicitudes de cola) a la SWQ, y es ortogonal a cualquier QoS aplicada por el hardware del dispositivo sobre cómo se aplica la QoS para compartir los recursos de ejecución del dispositivo al procesar las solicitudes de trabajo enviadas por diferentes productores. A continuación, se describen algunos ejemplos de enfoques para configurar los dispositivos finales para aplicar las políticas de admisión para aceptar las solicitudes de cola a SWQ. Se han documentado solo con fines ilustrativos y las opciones de implementación exactas serán específicas del dispositivo.
En una implementación, la instrucción MOVDIRI mueve el entero de doble palabra en el operando de origen (segundo operando) al operando destino (primer operando) usando una operación de almacén directo. El operando de origen puede ser un registro de propósito general. El operando de destino puede ser una ubicación de memoria de 32 bits. En el modo de 64 bits, el tamaño de operación por defecto de la instrucción es de 32 bits. MOVDIRI define el destino como alineado de doble palabra o de cuatro palabras.
Un almacén directo puede implementarse mediante el uso de un protocolo de tipo de memoria de combinación de escritura (WC) para escribir datos. Usando protocolo, el procesador no escribe los datos en la jerarquía de la caché, ni recupera la línea de caché correspondiente de la memoria en la jerarquía de la caché. Si la dirección de destino se almacena en la caché, la línea se vuelve a escribir (si se ha modificado) y se invalida de la caché, antes del almacén directo. A diferencia de los almacenes con sugerencia no temporal que permiten que el tipo de memoria sin caché (UC) y protegida contra escritura (WP) para el destino anule la sugerencia no temporal, los almacenes directos siempre siguen el protocolo de tipo de memoria WC independientemente del tipo de memoria de la dirección de destino (incluyendo los tipos UC y WP).
A diferencia de los almacenes WC y de los almacenes con una pista no temporal, los almacenes directos son elegibles para el desalojo inmediato de la memoria intermedia de combinación de escritura y, por lo tanto, no se combinan con almacenes más recientes (incluyendo los almacenes directos) a la misma dirección. Los almacenes antiguos de WC y no temporales que se mantienen en la memoria intermedia de escritura pueden combinarse con almacenes directos más recientes en la misma dirección.
Debido a que el protocolo de WC usado por los almacenes directos sigue un modelo de consistencia de memoria débilmente ordenada, una operación de cercado debe seguir la instrucción MOVDIRI para aplicar el orden cuando sea necesario.
Los almacenes directos se emiten por MOVDIRI a un destino alineado a un límite de 4 bytes y garantizan la atomicidad de la escritura de 4 bytes. Esto significa que los datos llegan al destino en una única transacción de escritura de 4 bytes (u 8 bytes) sin conflicto. Si el destino no está alineado para el tamaño de escritura, los almacenes directos emitidos por MOVDIRI se dividen y llegan al destino en dos partes. Cada parte de ese almacén directo dividida no se fusionará con los almacenes más jóvenes, sino que puede llegar al destino en cualquier orden.
La Figura 59 ilustra una realización de un método realizado por un procesador para procesar una instrucción MOVDIRI. Por ejemplo, se usa el hardware detallado en el presente documento.
En 5901, se obtiene una instrucción. Por ejemplo, se obtiene un MOVDIRI. La instrucción MOVDIRI incluye un código de operación (y en alguna realización un prefijo), un campo de destino que representa un operando de destino, y un campo de origen que representa el operando de registro de origen.
La instrucción obtenida se decodifica en 5903. Por ejemplo, la instrucción MOVDIRI se decodifica por un circuito de decodificación como el que se detalla en el presente documento.
Los valores de datos asociados con el operando de origen de la instrucción decodificada se recuperan en 5905. Además, en algunas realizaciones, la instrucción está planificada.
En 5907, la instrucción decodificada se ejecuta por circuitos de ejecución (hardware), como los que se detallan en el presente documento, para mover datos de tamaño de doble palabra desde el operando del registro de origen al operando del registro de destino sin almacenar los datos en caché.
En algunas realizaciones, la instrucción se confirma o se retira en 5909.
Mueve 64 bytes como un almacén directo con atomicidad de escritura de 64 bytes desde la dirección de memoria de origen a la de destino. El operando de origen es un operando de memoria normal. El operando de destino es una posición de memoria especificada en un registro de propósito general. El contenido del registro se interpreta como un desplazamiento en el segmento ES sin ninguna anulación de segmento. En el modo de 64 bits, la anchura del operando de registro es de 64 bits (o 32 bits). Fuera del modo de 64 bits, la anchura del registro es de 32 bits o 16 bits. MOVDIR64B requiere que la dirección de destino esté alineada a 64 bytes. No se aplica ninguna restricción de alineación para el operando de origen.
MOVDIR64B lee 64 bytes de la dirección de memoria de origen y realiza una operación de almacén directo de 64 bytes en la dirección de destino. La operación de carga sigue el orden normal de lectura basándose en el tipo de memoria de la dirección de origen. El almacén directo se implementa usando el protocolo de tipo de memoria de combinación de escritura (WC) para escribir datos. Usando este protocolo, el procesador puede no escribir los datos en la jerarquía de la caché, y puede no recuperar la línea de caché correspondiente de la memoria en la jerarquía de la caché. Si la dirección de destino se almacena en la caché, la línea se vuelve a escribir (si se ha modificado) y se invalida de la caché, antes del almacén directo.
A diferencia de los almacenes con una sugerencia no temporal que permiten que los tipos de memoria UC/WP para el destino anulen la sugerencia no temporal, los almacenes directos pueden seguir el protocolo del tipo de memoria WC independientemente del tipo de memoria de la dirección de destino (incluyendo los tipos UC/WP).
A diferencia de los almacenes WC y de los almacenes con sugerencias no temporales, los almacenes directos son elegibles para el desalojo inmediato de la memoria intermedia de combinación de escritura y, por lo tanto, no se combinan con almacenes más recientes (incluyendo los almacenes directos) la misma dirección. Los almacenes antiguos de WC y no temporales que se mantienen en la memoria intermedia de escritura pueden combinarse con almacenes directos más recientes en la misma dirección.
Dado que el protocolo WC usado por los almacenes directos sigue un modelo de consistencia de memoria débilmente ordenada, las operaciones de cercado deben seguir la instrucción MOVDIR64B para aplicar el orden cuando sea necesario.
No se garantiza la atomicidad de la operación de carga de 64 bytes desde la dirección de origen, y las implementaciones del procesador pueden usar múltiples operaciones de carga para leer los 64 bytes. El almacén directo de 64 bytes emitido por MOVDIR64B garantiza la atomicidad de la finalización de escritura de 64 bytes. Esto significa que los datos llegan al destino en una única transacción de escritura de 64 bytes sin conflicto.
La Figura 60 ilustra una realización de un método realizado por un procesador para procesar una instrucción MOVDIRI64B. Por ejemplo, se usa el hardware detallado en el presente documento.
En 6001, se obtiene una instrucción. Por ejemplo, se obtiene un MOVDIRI64B. La instrucción MOVDIRI64B incluye un código de operación (y en alguna realización un prefijo), un campo de destino que representa un operando de destino, y un campo de origen que representa el operando de registro de origen.
La instrucción obtenida se decodifica en 6003. Por ejemplo, la instrucción MOVDIRI64B se decodifica por un circuito de decodificación como el que se detalla en el presente documento.
Los valores de datos asociados con el operando de origen de la instrucción decodificada se recuperan en 6005. Además, en algunas realizaciones, la instrucción está planificada.
En 6007, la instrucción decodificada se ejecuta por circuitos de ejecución (hardware), como los que se detallan en el presente documento, para mover datos de 64 bytes desde el operando del registro de origen al operando del registro de destino sin almacenar los datos en caché.
En algunas realizaciones, la instrucción se confirma o se retira en 6009.
En una implementación, el comando ENQCMD pone en cola un comando de 64 bytes usando una escritura no publicada con atomicidad de escritura de 64 bytes desde la dirección de memoria de origen (segundo operando) a una dirección de memoria de cola de trabajo compartida (SWQ) del dispositivo en el operando de destino. El operando de origen es un operando de memoria normal. El operando de destino es una dirección de memoria especificada en un registro de propósito general. El contenido del registro se interpreta como un desplazamiento en el segmento ES sin ninguna anulación de segmento. En el modo de 64 bits, la anchura del operando de registro es de 64 bits o 32 bits. Fuera del modo de 64 bits, la anchura del registro es de 32 bits o 16 bits. ENQCMD requiere que la dirección de destino esté alineada a 64 bytes. No se aplica ninguna restricción de alineación para el operando de origen.
En una implementación, ENQCMD lee el comando de 64 bytes de la dirección de memoria de origen, formatea los datos de almacén de 64 bytes de la cola y realiza una operación de almacenamiento de 64 bytes de los datos de almacén a la dirección de destino. La operación de carga sigue el orden normal de lectura basándose en el tipo de memoria de la dirección de origen. Puede producirse un error de protección general si los 4 bytes inferiores de los datos de comando de 64 bytes leídos desde la dirección de memoria de origen tienen un valor distinto de cero, o si un bit del campo PASID válido es 0. De lo contrario, los datos del almacén de cola de 64 bytes tienen el siguiente formato:
Datos de almacén de cola [511:32] = datos de comando [511:32]
Datos de almacén de cola [31] = 0
Datos de almacén de cola [30:20] = 0
Datos de almacén de cola [19:0] = MSR de PASID [19:0]
En una implementación, los datos de almacén de cola de 64 bytes generados por ENQCMD tienen el formato ilustrado en la Figura 58. Los 60 bytes superiores del descriptor de comando especifican el comando específico del dispositivo de destino 5801. El campo PRIV 5802 (bit 31) puede forzarse a 0 para transmitir el privilegio de usuario para los almacenes en cola generados por la instrucción ENQCMD. El campo PASID (bits 19:0) 5804 transmite la identidad del espacio de direcciones del proceso (como se programó en MSR de PASID) asignada por el software del sistema para el hilo de software que ejecuta ENQCMD1.
La operación almacén de cola usa un protocolo de escritura no publicada para escribir 64 bytes de datos. El protocolo de escritura no publicada puede no escribir los datos en la jerarquía de la caché, y puede no recuperar la línea de caché correspondiente en la jerarquía de la caché. Los almacenes en cola siguen siempre el protocolo de escritura no publicada, independientemente del tipo de memoria de la dirección de destino (incluyendo los tipos UC/WP).
El protocolo de escritura no publicada puede devolver una respuesta de finalización para indicar el estado de éxito o de reintento de la escritura no publicada. La instrucción ENQCMD puede devolver este estado de finalización en una bandera cero (0 indica éxito y 1 indica reintento). El estado de éxito indica que los datos de escritura no publicados (64 bytes) son aceptados por la cola de trabajo compartida de destino (pero no necesariamente se actúa sobre ellos). El estado de reintento indica que la escritura no publicada no fue aceptada por la dirección de destino debido a la capacidad u otras razones temporales (o debido a que la dirección de destino no es una dirección válida de la cola de trabajo compartida).
En una implementación, como máximo un almacén de cola puede estar pendiente de un determinado procesador lógico. En ese sentido, un almacén de cola no puede pasar a otro almacén de cola. Los almacenes de cola no se ordenan contra los almacenes WB más antiguos, los almacenes WC y no temporales, CLFLUSHOPT o CLWB a diferentes direcciones. El software que necesite imponer este tipo de ordenamiento debe utilizar un cercado de almacenes explícito después de dichos almacenes y antes del almacén de cola. ENQCMD solo afecta a las direcciones de la cola de trabajo compartida (SWQ), que no se ven afectadas por otros almacenes.
No se garantiza la atomicidad de la operación de carga de 64 bytes desde la dirección de origen, y las implementaciones del procesador pueden usar múltiples operaciones de carga para leer los 64 bytes. El almacén de cola de 64 bytes emitido por ENQCMD garantiza la atomicidad de la finalización de escritura de 64 bytes. Los datos pueden llegar al destino como una única transacción de escritura de 64 bytes no publicada.
En algunas realizaciones, la instrucción ENQCMD usa un MSR de arquitectura PASID.
Figure imgf000085_0001
La Figura 61 ilustra una realización de un método realizado por un procesador para procesar una instrucción ENCQMD. Por ejemplo, se usa el hardware detallado en el presente documento.
En 6101, se obtiene una instrucción. Por ejemplo, se obtiene un ENCQMD. La instrucción ENCQMD incluye un código de operación (y en alguna realización un prefijo), un campo de destino que representa un operando de dirección de memoria de destino, y un campo de origen que representa el operando de memoria de origen.
La instrucción obtenida se decodifica en 6103. Por ejemplo, la instrucción ENCQMD se decodifica por un circuito de decodificación como el que se detalla en el presente documento.
Los valores de datos asociados con el operando de origen de la instrucción decodificada se recuperan en 6105. Además, en algunas realizaciones, la instrucción está planificada.
En 6107, la instrucción decodificada se ejecuta por circuitos de ejecución (hardware), como los que se detallan en el presente documento, para escribir un comando (los datos recuperados) en la dirección de memoria de destino. En algunas realizaciones, la dirección de memoria de destino es una dirección de cola de trabajo compartida.
En algunas realizaciones, la instrucción se confirma o se retira en 6109.
En una implementación, la instrucción ENQCMDS pone en cola el comando de 64 bytes usando una escritura no publicada con atomicidad de escritura de 64 bytes desde la dirección de memoria de origen (segundo operando) a una dirección de memoria de cola de trabajo compartida (SWQ) del dispositivo en el operando de destino. El operando de origen es un operando de memoria normal. El operando de destino es una dirección de memoria especificada en un registro de propósito general. El contenido del registro puede interpretarse como un desplazamiento en el segmento ES sin ninguna anulación de segmento. En el modo de 64 bits, la anchura del operando de registro es de 64 bits o 32 bits. Fuera del modo de 64 bits, la anchura del registro es de 32 bits o 16 bits. ENQCMD requiere que la dirección de destino esté alineada a 64 bytes. No se aplica ninguna restricción de alineación para el operando de origen.
A diferencia de ENQCMD (que puede ejecutarse desde cualquier nivel de privilegio), ENQCMDS es una instrucción con privilegio. Cuando el procesador está ejecutándose en modo protegido, CPL debe ser 0 para ejecutar esta instrucción. ENQCMDS lee el comando de 64 bytes de la dirección de memoria de origen, y realiza una operación de almacén de cola de 64 bytes usando estos datos a la dirección de destino. La operación de carga sigue el orden normal de lectura basándose en el tipo de memoria de la dirección de origen. Los datos del almacén de cola de 64 bytes tienen el siguiente formato:
Datos de almacén de cola [511:32] = datos de comando [511:32]
Datos de almacén de cola [31] = datos de comando [31]
Datos de almacén de cola [30:20] = 0
Datos de almacén de cola [19:0] = datos de comando [19:0]
Los datos del almacén de cola de 64 bytes generados por ENQCMDS pueden tener el mismo formato que ENQCMD. En una implementación, ENQCMDS tiene el formato ilustrado en la Figura 62.
Los 60 bytes superiores del descriptor de comando especifican el comando específico del dispositivo de destino 6201. El campo PRIV (bit 31) 6202 se especifica mediante el bit 31 de los datos del comando en la dirección del operando de origen para transmitir el privilegio de usuario (0) o de supervisor (1) para los almacenes en cola generados por la instrucción ENQCMDS. El campo PASID (bits 19:0) 6204 transmite la identidad del espacio de direcciones de proceso como se especifica en los bits 19:0 en los datos del comando en la dirección1 del operando de origen.
En una implementación, la operación almacén de cola usa un protocolo de escritura no publicada para escribir 64 bytes de datos. El protocolo de escritura no publicada no escribe los datos en la jerarquía de la caché, ni recupera la línea de caché correspondiente en la jerarquía de la caché. Los almacenes en cola siguen siempre el protocolo de escritura no publicada, independientemente del tipo de memoria de la dirección de destino (incluyendo los tipos UC/WP).
El protocolo de escritura no publicada devuelve una respuesta de finalización para indicar el estado de éxito o de reintento de la escritura no publicada. La instrucción ENQCMD devuelve este estado de finalización en una bandera cero (0 indica éxito y 1 indica reintento). El estado de éxito indica que los datos de escritura no publicados (64 bytes) son aceptados por la cola de trabajo compartida de destino (pero no necesariamente se actúa sobre ellos). El estado de reintento indica que la escritura no publicada no fue aceptada por la dirección de destino debido a la capacidad u otras razones temporales (o debido a que la dirección de destino no es una dirección válida de la cola de trabajo compartida).
Un procesador lógico puede tener como máximo un almacén de cola (ENQCMD o ENQCMDS). En ese sentido, un almacén de cola no puede pasar a otro almacén de cola. Los almacenes de cola no pueden ordenarse contra almacenes WB, WC y no temporales, CLFLUSHOPT o CLWB más antiguos a diferentes direcciones. El software que necesite aplicar tal ordenamiento puede usar una barrera de almacenes explícito después de tales almacenes y antes del almacén de cola.
ENQCMDS solo afecta a las direcciones de cola de trabajo compartida (SWQ), que no se ven afectadas por otros almacenes.
No se garantiza la atomicidad de la operación de carga de 64 bytes desde la dirección de origen, y las implementaciones del procesador pueden usar múltiples operaciones de carga para leer los 64 bytes. El almacén de cola de 64 bytes emitido por ENQCMDS garantiza la atomicidad de la finalización de escritura de 64 bytes (es decir, que llega al destino como una única transacción de escritura de 64 bytes no publicada).
La Figura 63 ilustra una realización de un método realizado por un procesador para procesar una instrucción ENCQMDs. Por ejemplo, se usa el hardware detallado en el presente documento.
En 6301, se obtiene una instrucción. Por ejemplo, se obtiene una ENCQMDs. La instrucción ENCQMDs incluye un código de operación (y en alguna realización un prefijo), un campo de destino que representa un operando de dirección de memoria de destino, y un campo de origen que representa el operando de memoria de origen.
La instrucción obtenida se decodifica en 6303. Por ejemplo, la instrucción ENCQMDs se decodifica por unos circuitos de decodificación tales como los que se detallan en el presente documento.
Los valores de datos asociados con el operando de origen de la instrucción decodificada se recuperan en 6305. Además, en algunas realizaciones, la instrucción está planificada.
En 6307, la instrucción decodificada se ejecuta, en un modo con privilegio, por circuitos de ejecución (hardware), como los que se detallan en el presente documento, para escribir un comando (los datos recuperados) en la dirección de memoria de destino. En algunas realizaciones, la dirección de memoria de destino es una dirección de cola de trabajo compartida.
En algunas realizaciones, la instrucción se confirma o se retira en 6309.
Una implementación utiliza dos instrucciones para garantizar una sincronización eficiente entre el acelerador y el procesador anfitrión: UMONITOR y UMWAIT. Brevemente, la instrucción UMONITOR arma el hardware de monitorización de direcciones usando una dirección especificada en un registro de origen y la instrucción UMWAIT instruye al procesador a entrar en un estado optimizado dependiente de la implementación mientras se monitoriza un rango de direcciones.
La instrucción UMONITOR arma el hardware de monitorización de direcciones usando una dirección especificada en el registro de origen r32/r64 (el rango de direcciones que el hardware de monitorización comprueba para las operaciones de almacenamiento puede determinarse usando una función de hoja de monitorización de CPUID. Un almacenamiento en una dirección dentro del rango de direcciones especificado activa el hardware de monitorización. El estado del hardware del monitor se usa por UMWAIT.
Las siguientes codificaciones de operandos se usan para una implementación de la instrucción UMONITOR:
Figure imgf000087_0001
Figure imgf000087_0002
El contenido del registro de origen r32/r64 es una dirección efectiva (en el modo de 64 bits, se usa r64). Por defecto, el segmento DS se usa para crear una dirección lineal que se monitoriza. Se pueden usar anulaciones de segmentos. El rango de direcciones debe usar memoria del tipo escritura no simultánea. Sólo se garantiza que la memoria de escritura no simultánea active correctamente el hardware de monitorización.
La instrucción UMONITOR se ordena como una operación de carga con respecto a otras transacciones de memoria. La instrucción está sujeta a la comprobación de permisos y fallos asociados a una carga de bytes. Al igual que una carga, UMONITOR establece el bit A, pero no el bit D en las tablas de páginas.
UMONITOR y UMWAIT pueden ejecutarse en cualquier nivel de privilegio. La operación de la instrucción es igual en los modos que no son de 64 bits y en el modo de 64 bits.
UMONITOR no interopera con la instrucción MWAIT heredada. Si UMONITOR se ejecutó antes de ejecutar MWAIT y después de la ejecución más reciente de la instrucción MONITOR heredada, MWAIT puede no entrar en un estado optimizado. La ejecución se reanudará con la instrucción siguiente al MWAIT.
La instrucción UMONITOR provoca un aborto transaccional cuando se usa dentro de una región transaccional. UMONITOR establece un rango de direcciones para el hardware del monitor usando el contenido del registro de origen como dirección efectiva y pone el hardware del monitor en estado armado. Un almacén al rango de direcciones especificado activará el hardware de monitor.
La Figura 64 ilustra una realización de un método realizado por un procesador para procesar una instrucción UMONITOR. Por ejemplo, se usa el hardware detallado en el presente documento.
En 6401, se obtiene una instrucción. Por ejemplo, se obtiene una UMONITOR. La instrucción UMONITOR incluye un código de operación (y en algunas realizaciones un prefijo) y un operando de registro de origen explícito.
La instrucción obtenida se decodifica en 6403. Por ejemplo, la instrucción UMONITOR se decodifica por unos circuitos de decodificación tales como los que se detallan en el presente documento.
Los valores de datos asociados con el operando de origen de la instrucción decodificada se recuperan en 6405. Además, en algunas realizaciones, la instrucción está planificada.
En 6407, la instrucción decodificada se ejecuta por circuitos de ejecución (hardware), tal como los que se detallan en el presente documento, para armar el hardware de monitorización para un almacén a una dirección definida por los datos de registro de origen recuperados.
En algunas realizaciones, la instrucción se confirma o se retira en 6409.
UMWAIT instruye al procesador para que entre en un estado optimizado dependiente de la implementación mientras monitoriza un rango de direcciones. El estado optimizado puede ser un estado optimizado de potencia/rendimiento ligero o un estado optimizado de potencia/rendimiento mejorado. La selección entre los dos estados se rige por el operando de origen del registro de entrada explícito bit[0].
TABLA
Figure imgf000088_0001
Figure imgf000088_0002
UMWAIT puede ejecutarse en cualquier nivel de privilegio. La operación de esta instrucción es igual en los modos que no son de 64 bits y en el modo de 64 bits.
El registro de entrada puede contener información tal como el estado optimizado preferido en el que debe entrar el procesador, como se describe en la siguiente tabla. Los bits distintos de 0 están reservados y darán como resultado #GP si no es cero.
TABLA MM
Figure imgf000088_0003
La instrucción se reactiva cuando el contador de indicación de tiempo alcanza o supera el valor de entrada implícito de 64 bits (si el hardware de monitorización no se ha activado antes).
Antes de ejecutar la instrucción UMWAIT, un sistema operativo puede especificar el retardo máximo que permite al procesador suspender su operación en el que puede incluir cualquiera de los dos estados optimizados de energía/rendimiento. Puede hacerlo escribiendo el valor de TSC-quanta en el siguiente MSR de 32 bits:
UMWAIT_CONTROL[31:2] - Determina el tiempo máximo en TSC-quanta que el procesador puede residir en cualquiera de C0.1 o C0.2. El valor cero indica que el SO no plantea ningún límite al procesador. El valor máximo de tiempo es un valor de 32b donde los 30b superiores provienen de este campo y los dos bits inferiores se asumen como cero.
UMWAIT_CONTROL[1] - Reservado.
UMWAIT_CONTROL[0] - C0.2 no está permitido por el SO. Un valor de 1 significa que todas las solicitudes C0.2 vuelven a ser C0.1
En una implementación, si el procesador que ejecutó una instrucción UMWAIT se reactiva debido a la expiración del límite de tiempo del sistema operativo, la instrucción establece una bandera de acarreo; de lo contrario, esa bandera se borra.
La instrucción UMWAIT provoca un aborto transaccional cuando se usa dentro de una región transaccional. En una implementación, la instrucción UMWAIT opera con la instrucción UMONITOR. Las dos instrucciones permiten definir una dirección en la que esperar (UMONITOR) y una operación optimizada dependiente de la implementación para comenzar en la dirección de espera (UMWAIT). La ejecución de UMWAIT es una sugerencia al procesador de que puede entrar en un estado optimizado dependiente de la implementación mientras espera un evento o una operación de almacenamiento en el rango de direcciones armado por UMONITOR.
Lo siguiente puede hacer que el procesador salga del estado optimizado dependiente de la implementación: un almacén en el rango de direcciones armado por la instrucción UMONITOR, una interrupción no enmascarable (NMI) o una interrupción de gestión del sistema (SMI), una excepción de depuración, una excepción de comprobación de máquina, la señal BINIT#, la señal INIT# y la señal RESET#. Otros eventos dependientes de la implementación también pueden hacer que el procesador salga del estado optimizado dependiente de la implementación.
Además, una interrupción externa puede hacer que el procesador salga del estado optimizado dependiente de la implementación, independientemente de si las interrupciones enmascarables están inhibidas.
Tras la salida del estado de optimización dependiente de la implementación, el control pasa a la instrucción que sigue a la instrucción UMWAIT. Una interrupción pendiente que no está enmascarada (incluyendo una NMI o una SMI) puede entregarse antes de la ejecución de esa instrucción.
A diferencia de la instrucción HLT, la instrucción UMWAIT no soporta un reinicio en la instrucción UMWAIT tras la gestión de una SMI. Si la instrucción UMONITOR precedente no armó con éxito un rango de direcciones o si UMONITOR no se ejecutó antes de ejecutar UMWAIT y después de la ejecución más reciente de la instrucción MONITOR heredada (UMWAIT no interopera con MONITOR), entonces el procesador no entrará en un estado optimizado. La ejecución se reanudará con la instrucción siguiente al UMWAIT.
Obsérvese que UMWAIT se usa para entrar en los estados C0-sub que son numéricamente más bajos que C1, por lo que un almacén en el rango de direcciones armado por la instrucción UMONITOR hará que el procesador salga de UMWAIT si el almacenamiento fue originado por otros agentes del procesador o el almacenamiento fue originado por un agente no procesador.
La Figura 65 ilustra una realización de un método realizado por un procesador para procesar una instrucción UMWAIT. Por ejemplo, se usa el hardware detallado en el presente documento.
En 6501, se obtiene una instrucción. Por ejemplo, se obtiene un UMWAIT. La instrucción UMWAIT incluye un código de operación (y en algunas realizaciones un prefijo) y un operando de registro de origen explícito.
La instrucción obtenida se decodifica en 6503. Por ejemplo, la instrucción UMWAIT se decodifica por un circuito de decodificación como el que se detalla en el presente documento.
Los valores de datos asociados con el operando de origen de la instrucción decodificada se recuperan en 6505. Además, en algunas realizaciones, la instrucción está planificada.
En 6507, la instrucción decodificada se ejecuta por circuitos de ejecución (hardware), tales como los que se detallan en el presente documento, para entrar el procesador (o núcleo) en un estado dependiente de la implementación, definido por los datos del operando de registro de origen explícito, mientras se monitoriza un rango de direcciones. En algunas realizaciones, la instrucción se confirma o se retira en 6509.
TPAUSE instruye al procesador que entre en un estado optimizado dependiente de la implementación. Hay dos estados optimizados para elegir: el estado optimizado de potencia/rendimiento ligero y el estado optimizado de potencia/rendimiento mejorado. La selección entre los dos se rige por el operando de origen del registro de entrada explícito bit[0].
Figure imgf000089_0001
TABLA OO
Figure imgf000090_0001
TPAUSE puede ejecutarse en cualquier nivel de privilegio. La operación de esta instrucción es igual en los modos que no son de 64 bits y en el modo de 64 bits.
A diferencia de PAUSE, la instrucción TPAUSE no provocará un aborto cuando se utilice dentro de una región transaccional. El registro de entrada contiene información tal como el estado optimizado preferido en el que debe entrar el procesador, como se describe en la siguiente tabla. Los bits distintos de 0 están reservados y darán como resultado #GP si no es cero.
TABLA PP
Figure imgf000090_0002
La instrucción se reactiva cuando el contador de indicación de tiempo alcanza o supera el valor de entrada implícito de 64 bits (si el hardware de monitorización no se ha activado antes). Antes de ejecutar la instrucción TPAUSE, un sistema operativo puede especificar el retardo máximo que permite al procesador suspender su operación en cualquiera de los dos estados optimizados de energía/rendimiento. Puede hacerlo escribiendo el valor de TSC-quanta en el siguiente MSR de 32 bits:
UMWAIT_CONTROL[31:2] - Determina el tiempo máximo en TSC-quanta que el procesador puede residir en cualquiera de C0.1 o C0.2. El valor cero indica que el SO no plantea ningún límite al procesador. El valor máximo de tiempo es un valor de 32b donde los 30b superiores provienen de este campo y los dos bits inferiores se asumen como cero.
UMWAIT_CONTROL[1] - Reservado.
UMWAIT_CONTROL[0] - C0.2 no está permitido por el SO. El valor de 1 significa que todas las solicitudes C0.2 vuelven ser C0.1
El motivo de la reactivación debido a la expiración del límite de tiempo del sistema operativo puede indicarse mediante el establecimiento de una bandera de acarreo.
Si el procesador que ejecutó una instrucción TPAUSE se reactiva debido a la expiración del límite de tiempo del sistema operativo, las instrucciones establecen una bandera de acarreo; de lo contrario, esa bandera se borra.
Para monitorizar múltiples rangos de direcciones, la instrucción TPAUSE puede colocarse dentro de una región transaccional que se compone de un conjunto de direcciones a monitorizar y una instrucción TPAUSE posterior. La región transaccional permite la definición de un conjunto de direcciones en las que esperar y una operación optimizada dependiente de la implementación para comenzar en la ejecución de la instrucción TPAUSE. En una implementación, la ejecución de TPAUSE dirige al procesador a entrar en un estado optimizado dependiente de la implementación mientras espera un evento o una operación de almacenamiento a las direcciones en el rango definido por el conjunto de lectura.
El uso de TPAUSE dentro de una región de memoria transaccional puede limitarse a C0.1 (el estado de potencia/rendimiento optimizado ligero). Incluso si el software establece el bit[0]=0 para indicar su preferencia por C0.2 (estado de energía/rendimiento optimizado mejorado), el procesador puede entrar en C0.1.
Lo siguiente puede hacer que el procesador salga del estado optimizado dependiente de la implementación: un almacén al rango del conjunto de lectura dentro de la región transaccional, una NMI o SMI, una excepción de depuración, una excepción de comprobación de máquina, la señal BINIT#, la señal INIT# y la señal RESET#. Todos estos eventos también abortarán la transacción.
Otros eventos dependientes de la implementación pueden hacer que el procesador salga del estado optimizado dependiente de la implementación, y pueden dar como resultado una región transaccional no abortada, continuando a la instrucción siguiente a TPAUSE. Además, una interrupción externa hace que el procesador salga del estado optimizado dependiente de la implementación, independientemente de si las interrupciones enmascarables están inhibidas, en algunas realizaciones. Debe observarse que, en el caso de que las interrupciones enmascarables estén inhibidas, la ejecución continuará con la instrucción siguiente a TPAUSE, mientras que en el caso de que se establezca una bandera de interrupciones activada, la región transaccional se abortará.
La Figura 66 ilustra una realización de un método realizado por un procesador para procesar una instrucción TPAUSE. Por ejemplo, se usa el hardware detallado en el presente documento.
En 6601, se obtiene una instrucción. Por ejemplo, se obtiene un TPAUSE. La instrucción TPAUSE incluye un código de operación (y en algunas realizaciones un prefijo) y un operando de registro de origen explícito.
La instrucción obtenida se decodifica en 6603. Por ejemplo, la instrucción TPAUSE se decodifica por un circuito de decodificación como el que se detalla en el presente documento.
Los valores de datos asociados con el operando de origen de la instrucción decodificada se recuperan en 6605. Además, en algunas realizaciones, la instrucción está planificada.
En 6607, la instrucción decodificada se ejecuta por circuitos de ejecución (hardware), tales como los que se detallan en el presente documento, para entrar el procesador (o núcleo) en un estado específico de implementación definido por los datos del operando de registro de origen explícito.
En algunas realizaciones, la instrucción se confirma o se retira en 6609.
La Figura 67 ilustra un ejemplo de ejecución que usa las instrucciones UMWAIT y UMONITOR.
En 6701, se ejecuta una instrucción UMWAIT para establecer un rango de direcciones a monitorizar.
En 6703, se ejecuta una instrucción UMONITOR para que el núcleo que ejecuta la instrucción entre en un estado dependiente de la implementación, definido por los datos del operando del registro de origen explícito de la instrucción, para el rango de direcciones que se está monitorizando.
El estado dependiente de la implementación se abandona en uno de los siguientes casos: un almacenamiento en las direcciones monitorizadas, una NMI, una SMI, una excepción de depuración, una excepción de comprobación de máquina, una señal de inicialización o una señal de reseteo en 6705.
La Figura 68 ilustra un ejemplo de ejecución que usa las instrucciones TPAUSE y UMONITOR.
En 6801, se ejecuta una instrucción TPAUSE para establecer un rango de direcciones a monitorizar.
En 6803, se ejecuta una instrucción UMONITOR para que el núcleo que ejecuta la instrucción entre en un estado dependiente de la implementación, definido por los datos del operando del registro de origen explícito de la instrucción, para el rango de direcciones que se está monitorizando.
El estado dependiente de la implementación se abandona en uno de los siguientes casos: un almacenamiento en las direcciones monitorizadas, una NMI, una SMI, una excepción de depuración, una excepción de comprobación de máquina, una señal de inicialización o una señal de reseteo en 6805.
La transacción asociada al hilo se aborta al salir del estado dependiente de la implementación en 6807.
En algunas implementaciones, un acelerador se acopla a los núcleos del procesador o a otros elementos de procesamiento para acelerar ciertos tipos de operaciones, tales como las operaciones gráficas, las operaciones de aprendizaje automático, las operaciones de análisis de patrones y (como se describe en detalle más adelante) las operaciones de multiplicación de matrices dispersas, por nombrar algunas. El acelerador puede estar acoplado comunicativamente al procesador/núcleos a través de un bus u otra interconexión (por ejemplo, una interconexión punto a punto) o puede estar integrado en el mismo chip que el procesador y acoplado comunicativamente a los núcleos a través de un bus/interconexión interna del procesador. Independientemente de la forma en que se conecte el acelerador, los núcleos del procesador pueden asignar ciertas tareas de procesamiento al acelerador (por ejemplo, en forma de secuencias de instrucciones o uops) que incluye circuitos/lógica especializada para procesar eficientemente estas tareas.
La Figura 69 ilustra una implementación ilustrativa en la que un acelerador 6900 está acoplado comunicativamente a una pluralidad de núcleos 6910-6911 a través de una interfaz coherente de caché 6930. Cada uno de los núcleos 6910-6911 incluye una memoria intermedia de traducción anticipada 6912-6913 para almacenar traducciones de direcciones virtuales a físicas y una o más cachés 6914-6915 (por ejemplo, caché L1, caché L2, etc.) para almacenar datos e instrucciones. Una unidad de gestión de memoria 6920 gestiona el acceso de los núcleos 6910-6911 a la memoria del sistema 6950, que puede ser una memoria de acceso aleatorio dinámico DRAM. Una caché compartida 6926, tal como una caché L3, puede compartirse entre los núcleos del procesador 6910-6911 y con el acelerador 6900 a través de la interfaz coherente de caché 6930. En una implementación, los núcleos 6910-1011, la MMU 6920 y la interfaz coherente de caché 6930 están integrados en un único chip de procesador.
El acelerador 6900 ilustrado incluye una unidad de gestión de datos 6905 con una caché 6907 y un planificador 6906 para planificar operaciones a una pluralidad de elementos de procesamiento 6901-6902, N. En la implementación ilustrada, cada elemento de procesamiento tiene su propia memoria local 6903-6904, N. Como se describe en detalle más adelante, cada memoria local 6903-6904, N puede implementarse como una DRAM apilada.
En una implementación, la interfaz coherente de caché 6930 proporciona conectividad coherente de caché entre los núcleos 6910-6911 y el acelerador 6900, tratando en efecto al acelerador como un par de los núcleos 6910-6911. Por ejemplo, la interfaz coherente de caché 6930 puede implementar un protocolo de coherencia de caché para asegurar que los datos accedidos/modificados por el acelerador 6900 y almacenados en la caché del acelerador 6907 y/o en las memorias locales 6903-6904, N sean coherentes con los datos almacenados en las cachés del núcleo 6910-6911, la caché compartida 6926 y la memoria del sistema 6950. Por ejemplo, la interfaz coherente de caché 6930 puede participar en los mecanismos de sondeo usados por los núcleos 6910-6911 y la MMU 6920 para detectar el estado de las líneas de caché dentro de la caché compartida 6926 y las cachés locales 6914-6915 y puede actuar como un intermediario, proporcionando actualizaciones de sondeo en respuesta a los accesos e intentos de modificación de las líneas de caché por los elementos de procesamiento 6901-6902, N. Además, cuando una línea de caché es modificada por los elementos de procesamiento 6901-6902, N, la interfaz coherente de caché 6930 puede actualizar el estado de las líneas de caché si están almacenadas dentro de la caché compartida 6926 o las cachés locales 6914­ 6915.
En una implementación, la unidad de gestión de datos 1005 incluye circuitos de gestión de memoria que proporcionan al acelerador 6900 acceso a la memoria del sistema 6950 y a la caché compartida 6926. Además, la unidad de gestión de datos 6905 puede proporcionar actualizaciones a la interfaz coherente de caché 6930 y recibir actualizaciones de la interfaz coherente de caché 6930 según sea necesario (por ejemplo, para determinar los cambios de estado de las líneas de caché). En la implementación ilustrada, la unidad de gestión de datos 6905 incluye un planificador 6906 para planificar las instrucciones/operaciones a ejecutar por los elementos de procesamiento 6901-6902. Para realizar sus operaciones de planificación, el planificador 6906 puede evaluar las dependencias entre instrucciones/operaciones para garantizar que las instrucciones/operaciones se ejecutan en un orden coherente (por ejemplo, para garantizar que una primera instrucción se ejecuta antes de una segunda instrucción que depende de los resultados de la primera instrucción). Las instrucciones/operaciones que no son interdependientes pueden ejecutarse en paralelo en los elementos de procesamiento 6901-6902.
La Figura 70 ilustra otra vista del acelerador 6900 y otros componentes previamente descritos, incluyendo una unidad de gestión de datos 6905, una pluralidad de elementos de procesamiento 6901-N, y un almacenamiento rápido en el chip 7000 (por ejemplo, implementado usando DRAM local apilada en una implementación). En una implementación, el acelerador 6900 es una arquitectura de acelerador de hardware y los elementos de procesamiento 6901 -N incluyen circuitos para realizar operaciones matriciales * vectoriales y vectoriales * vectoriales, incluyendo operaciones para matrices dispersas/densas. En particular, los elementos de procesamiento 6901-N pueden incluir soporte de hardware para el procesamiento de matrices orientadas a columnas y filas y pueden incluir soporte microarquitectónico para una operación de "escala y actualización" tal como la usada en los algoritmos de aprendizaje automático (ML).
Las implementaciones descritas realizan operaciones matriciales/vectoriales que se optimizan manteniendo los datos vectoriales de uso frecuente, de acceso aleatorio y potencialmente dispersos (por ejemplo, recopilar/dispersar) en el almacenamiento rápido en el chip 7000 y manteniendo los datos matriciales grandes y de uso infrecuente en la memoria fuera del chip (por ejemplo, la memoria del sistema 6950), a los que se accede en forma de flujo continuo siempre que sea posible, y exponiendo el paralelismo de bloque intra/inter matricial para escalar.
Las implementaciones de los elementos de procesamiento 6901-N procesan diferentes combinaciones de matrices dispersas, matrices densas, vectores dispersos y vectores densos. Como se usa en el presente documento, una matriz o vector "disperso" es una matriz o vector en el que la mayoría de los elementos son cero. Por el contrario, una matriz o vector "denso" es una matriz o vector en el que la mayoría de los elementos son distintos de cero. La "dispersión" de una matriz/vector puede definirse basándose en el número de elementos de valor cero dividido por el número total de elementos (por ejemplo, m x n para una matriz m x n). En una implementación, una matriz/vector se considera "dispersa" si su dispersión está por encima de un umbral especificado.
Un conjunto ilustrativo de operaciones realizadas por los elementos de procesamiento 6901 -N se ilustra en la tabla de la Figura 71. En particular, los tipos de operación incluyen una primera multiplicación 7100 usando una matriz dispersa, una segunda multiplicación 7101 usando una matriz densa, una operación de escala y actualización 7102 y una operación de producto escalar 7103. Se proporcionan columnas para un primer operando de entrada 7110 y un segundo operando de entrada 7111 (cada uno de los cuales puede incluir una matriz/vector disperso o denso); un formato de salida 7112 (por ejemplo, vector denso o escalar); un formato de datos matriciales (por ejemplo, fila dispersa comprimida, columna dispersa comprimida, orientada a filas, etc.) 7113; y un identificador de operación 7114.
Los patrones de cómputo que dominan el tiempo de ejecución que se encuentran en algunas cargas de trabajo actuales incluyen variaciones de multiplicación de matrices contra un vector en forma orientada a filas y columnas.
Funcionan con formatos de matriz bien conocidos: fila dispersa comprimida (CSR) y columna dispersa comprimida (CSC). La Figura 72A representa un ejemplo de una multiplicación entre una matriz dispersa A contra un vector x para producir un vector y. La Figura 72B ilustra la representación CSR de la matriz A en la que cada valor se almacena como un par (valor, índice de fila). Por ejemplo, el (3,2) para la fila 0 indica que se almacena un valor de 3 en la posición 2 del elemento para la fila 0. La Figura 72C ilustra una representación CSC de la matriz A que usa un par (valor, índice de columna).
Las Figuras 73A, 73B y 73C ilustran el pseudocódigo de cada patrón de cálculo, que se describe a continuación en detalle. En particular, la Figura 73A ilustra una multiplicación de vectores densos de matriz dispersa orientada a filas (spMdV_csr); La Figura 73B ilustra una multiplicación de vectores dispersos de matriz orientada a columnas (spMspC_csc); y la Figura 73C ilustra una operación de escala y actualización (scale_update).
A. Multiplicación de vectores densos de matriz dispersa orientada a filas (spMdV_csr)
Se trata de un patrón de computación bien conocido que es importante en muchos dominios de aplicación, tal como la computación de alto rendimiento. En este punto, para cada fila de la matriz A, se realiza un producto escalar de esa fila contra el vector x, y el resultado se almacena en el elemento del vector y apuntado por el índice de la fila. Este cálculo se utiliza en un algoritmo de aprendizaje automático (ML) que realiza un análisis a través de un conjunto de muestras (es decir, filas de la matriz). Puede usarse en técnicas como el "minilote". También hay casos en los que los algoritmos de ML solo realizan un producto escalar de un vector disperso contra un vector denso (es decir, una iteración del bucle spMdV_csr), tal como en las variantes estocásticas de los algoritmos de aprendizaje.
Un factor conocido que puede afectar al rendimiento de este cálculo es la necesidad de acceder aleatoriamente a elementos dispersos del vector x en el cálculo del producto escalar. Para un sistema de servidor convencional, cuando el vector x es grande, esto daría lugar a accesos irregulares (recopilación) a la memoria o a la caché de último nivel.
Para solucionar esto, una implementación de un elemento de procesamiento divide la matriz A en bloques de columnas y el vector x en múltiples subconjuntos (cada uno correspondiente a un bloque de columnas de la matriz A). El tamaño del bloque puede elegirse de forma que el subconjunto de vectores x pueda encajar en el chip. Por lo tanto, los accesos aleatorios al mismo pueden ubicarse en el chip.
B. Multiplicación de vectores dispersos de matriz orientada a columnas (spMspV_csc)
Este patrón que multiplica una matriz dispersa contra un vector disperso no es tan conocido como spMdV_csr. Sin embargo, es importante en algunos algoritmos de ML. Se usa cuando un algoritmo trabaja con un conjunto de características, que se representan como columnas de la matriz en el conjunto de datos (de ahí la necesidad de accesos a la matriz orientada a columnas).
En este patrón de cálculo, cada columna de la matriz A se lee y se multiplica por el elemento correspondiente no cero del vector x. El resultado se usa para actualizar los productos escalares parciales que se mantienen en el vector y. Una vez procesadas todas las columnas asociadas a los elementos del vector x que no son cero, el vector y contendrá los productos escalares finales.
Mientras que los accesos a la matriz A son regulares (es decir, el flujo en las columnas de A), los accesos al vector y para actualizar los productos escalares parciales son irregulares. El elemento y al que se accede depende del índice de fila del elemento del vector A que se está procesando. Para solucionar esto, la matriz A puede dividirse en bloques de filas. En consecuencia, el vector y puede dividirse en subconjuntos correspondientes a estos bloques. De este modo, al procesar un bloque de filas de la matriz, solo necesita acceder de forma irregular (recopilar/dispersión) a su subconjunto de vectores y. Si se elige bien el tamaño del bloque, el subconjunto de vectores y puede mantenerse en el chip.
C. Escalar y actualizar (scale_update)
Los algoritmos de ML típicamente usan este patrón para aplicar factores de escala a cada muestra de la matriz y reducirlos a un conjunto de pesos, cada uno de los cuales corresponde a una característica (es decir, a una columna de A). En este punto, el vector x contiene los factores de escala. Para cada fila de la matriz A (en formato CSR), los factores de escala para esa fila se leen del vector x, y, a continuación, se aplican a cada elemento de A en esa fila. El resultado se usa para actualizar el elemento del vector y. Una vez procesadas todas las filas, el vector y contiene los pesos reducidos.
Al igual que los patrones de cálculo anteriores, los accesos irregulares al vector y podrían afectar al rendimiento cuando y es grande. Dividir la matriz A en bloques de columnas y el vector y en múltiples subconjuntos correspondientes a estos bloques puede ayudar a localizar los accesos irregulares dentro de cada subconjunto y.
Una implementación incluye un acelerador de hardware que puede realizar eficientemente los patrones de cálculo analizados anteriormente. El acelerador es un bloque de IP de hardware que puede integrarse con procesadores de propósito general. En una implementación, el acelerador 6900 accede independientemente a la memoria 6950 a través de una interconexión compartida con los procesadores para realizar los patrones de cálculo. Soporta cualquier conjunto de datos matriciales arbitrariamente grandes que residen en la memoria fuera del chip.
La Figura 74 ilustra el flujo de procesamiento para una implementación de la unidad de gestión de datos 6905 y los elementos de procesamiento 6901-6902. En esta implementación, la unidad de gestión de datos 6905 incluye un planificador de elementos de procesamiento 7401, una memoria intermedia de lectura 7402, una memoria intermedia de escritura 7403 y una unidad de reducción 7404. Cada PE 6901-6902 incluye una memoria intermedia de entrada 7405-7406, un multiplicador 7407-7408, un sumador 7409-7410, una RAM local 7421 -7422, un registro de suma 7411 -7412, y una memoria intermedia de salida 7413-7414.
El acelerador soporta los esquemas de bloqueo de matrices analizados anteriormente (es decir, el bloqueo de filas y columnas) para soportar cualquier dato de matriz de tamaño arbitrario. El acelerador está diseñado para procesar un bloque de datos matriciales. Cada bloque se divide a su vez en sub-bloques que se procesan en paralelo por los Pes 6901-6902.
En operación, la unidad de gestión de datos 6905 lee las filas o columnas de la matriz desde el subsistema de memoria en su memoria intermedia de lectura 7402, que a continuación se distribuye dinámicamente por el programador PE 7401 entre los PE 6901 -6902 para su procesamiento. También escribe los resultados en la memoria desde su memoria intermedia de escritura 7403.
Cada PE 6901 -6902 es responsable de procesar un sub-bloque de la matriz. Un PE contiene una memoria RAM en el chip 7421 -7422 para almacenar el vector al que hay que acceder aleatoriamente (es decir, un subconjunto del vector x o y, como se ha descrito anteriormente). También contiene una unidad de multiplicación-acumulación en coma flotante (FMA) que incluye el multiplicador 7407-7408 y el sumador 7409-7410 y la lógica de desempaquetado dentro de las memorias intermedias de entrada 7405-7406 para extraer los elementos de la matriz de los datos de entrada, y un registro de suma 7411 -7412 para mantener los resultados acumulados de la FMA.
Una implementación del acelerador consigue una eficiencia extrema porque (1) coloca los datos de acceso irregular (recopilar/dispersar) en las RAM de los PE en el chip 7421-7422, (2) utiliza un planificador de PE por hardware 7401 para garantizar que los PE están bien utilizados, y (3) a diferencia de los procesadores de propósito general, el acelerador consiste solo en los recursos de hardware que son esenciales para las operaciones de matrices dispersas. En general, el acelerador convierte eficazmente en rendimiento el ancho de banda de memoria disponible que se le proporciona.
El escalado del rendimiento puede hacerse empleando más PE en un bloque acelerador para procesar múltiples sub­ bloques de matriz en paralelo, y/o empleando más bloques aceleradores (cada uno tiene un conjunto de PE) para procesar múltiples bloques de matriz en paralelo. A continuación, se considera una combinación de estas opciones. El número de PE y/o bloques aceleradores debe ajustarse para que coincida con el ancho de banda de la memoria.
Una implementación del acelerador 6900 puede ser programada a través de una biblioteca de software. Tal biblioteca prepara los datos de la matriz en la memoria, establece los registros de control en el acelerador 6900 con información sobre el cálculo (por ejemplo, el tipo de cálculo, el puntero de memoria a los datos de la matriz), e inicia el acelerador. A continuación, el acelerador accede de forma independiente a los datos de la matriz en la memoria, realiza el cálculo y escribe los resultados en la memoria para que el software los consuma.
El acelerador maneja los diferentes patrones de cómputo ajustando sus PE a la configuración apropiada de la ruta de datos, como se representa en las Figuras 75A-B. En particular, la Figura 75a resalta las rutas (usando líneas discontinuas de puntos) para las operaciones spMspV_csc y scale_update y la Figura 75b ilustra las rutas para una operación spMdV_csr. A continuación, se detalla la operación del acelerador para realizar cada patrón de cálculo.
Para spMspV_csc, el subconjunto inicial de vectores y se carga en la RAM 7421 del PE por la DMU 6905. A continuación, lee x elementos del vector de la memoria. Para cada elemento x, la DMU 6905 envía por flujo continuo los elementos de la columna de la matriz correspondiente desde la memoria y los suministra al PE 6901. Cada elemento de la matriz contiene un valor (A.val) y un índice (A.idx) que apunta al elemento y que va a leerse de la RAM 7421 del PE. La DMU 6905 también proporciona el elemento del vector x (x.val) que se multiplica contra A.val por la unidad de multiplicación-acumulación (FMA). El resultado se usa para actualizar el elemento y en la RAM del PE apuntado por A.idx. Obsérvese que, aunque no se usa en nuestras cargas de trabajo, el acelerador también soporta la multiplicación por columnas contra un vector x denso (spMdV_csc) procesando todas las columnas de la matriz en lugar de solo un subconjunto (ya que x es denso).
La operación scale_update es similar a la de spMspV_csc, salvo que la DMU 6905 lee las filas de una matriz A representada en formato CSR en lugar de CSC. Para spMdV_csr, el subconjunto de vectores x se carga en la RAM 7421 del PE. La DMU 6905 transmite los elementos de la fila de la matriz (es decir, los pares {A.val,A.idx}) desde la memoria. A.idx se usa para leer el elemento del vector x apropiado de la RAM 7421, que se multiplica contra A.val por la FMA. Los resultados se acumulan en el registro de suma 7412. El registro de suma se escribe en la memoria intermedia de salida cada vez que un PE ve un marcador que indica el final de una fila, que se suministra por la DMU 6905. De este modo, cada PE produce una suma para el sub-bloque de fila del que es responsable. Para producir la suma final de la fila, las sumas de los sub-bloques producidas por todos los PE son sumadas por la unidad de reducción 7404 en la DMU (véase la Figura 74). Las sumas finales se escriben en la memoria intermedia de salida 7413-7414, que la DMU 6905 escribe a continuación en la memoria.
Procesamiento de datos grafos
En una implementación, las arquitecturas del acelerador descritas en el presente documento están configuradas para procesar datos de grafos. El análisis de grafos se basa en algoritmos de grafos para extraer conocimientos sobre la relación entre los datos representados como grafos. La proliferación de datos de grafos (procedentes de fuentes como las redes sociales) ha provocado una fuerte demanda y un amplio uso de los análisis grafos. Por ello, es fundamental poder realizar análisis de grafos de la forma más eficiente posible.
Para responder a esta necesidad, una implementación mapea automáticamente un algoritmo de grafo definido por el usuario a una "plantilla" de arquitectura de acelerador de hardware que se adapta al algoritmo de grafo de entrada dado. El acelerador puede comprender las arquitecturas descritas anteriormente y puede implementarse como un FPGA/ASIC, que puede ejecutarse con una eficiencia extrema. En resumen, una implementación incluye:
(1) una plantilla de arquitectura de acelerador de hardware que se basa en un acelerador de multiplicación vectorial de matriz dispersa generalizada (GSPMV). Soporta un algoritmo de grafo arbitrario porque se ha demostrado que el algoritmo de grafo puede formularse como operaciones matriciales.
(2) un enfoque automático para mapear y ajustar una abstracción de programación de grafos "centrada en los vértices", ampliamente utilizada, a la plantilla de arquitectura.
Existen aceleradores hardware de multiplicación de matrices dispersas, pero no soportan la personalización para permitir el mapeo de algoritmos de grafos.
Una implementación de la estructura de diseño opera como sigue.
(1) Un usuario especifica un algoritmo de grafos como "programas de vértices" siguiendo la abstracción de programación de grafos centrada en los vértices. Esta abstracción se elige como ejemplo en este punto debido a su popularidad. Un programa de vértices no expone los detalles del hardware, por lo que usuarios sin experiencia en hardware (por ejemplo, científicos de datos) pueden crearlo.
(2) Junto con el algoritmo de grafo en (1), una implementación de la estructura acepta las siguientes entradas:
a. Los parámetros del acelerador de hardware de destino que se va a generar (por ejemplo, la cantidad máxima de RAM en el chip). Estos parámetros pueden proporcionarse por un usuario, u obtenerse de una biblioteca existente de parámetros conocidos cuando se dirige a un sistema existente (por ejemplo, una placa FPGA particular).
b. Objetivos de optimización del diseño (por ejemplo, rendimiento máximo, área mínima)
c. Las propiedades de los datos del grafo de destino (por ejemplo, el tipo de grafo) o los propios datos del grafo. Esto es opcional y se usa para ayudar a la sintonización automática.
(3) Dadas las entradas anteriores, una implementación de la estructura de trabajo lleva a cabo el autoajuste para determinar el conjunto de personalizaciones a aplicar a la plantilla de hardware para optimizar el algoritmo de grafo de entrada, mapear estos parámetros en la plantilla de arquitectura para producir una instancia de acelerador en RTL sintetizable, y llevar a cabo la validación funcional y de rendimiento de la RTL generada contra los modelos de software funcionales y de rendimiento derivados de la especificación del algoritmo de grafo de entrada.
En una implementación, la arquitectura del acelerador descrita anteriormente se amplía para soportar la ejecución de programas de vértices (1) convirtiéndola en una plantilla de hardware personalizable y (2) soportando las funcionalidades necesarias para el programa de vértices. Basándose en esta plantilla, se describe una estructura de diseño para mapear un programa de vértices suministrado por el usuario a la plantilla de hardware para producir una instancia de implementación RTL sintetizable (por ejemplo, Verilog) optimizada para el programa de vértices. La estructura también realiza la validación y el ajuste automáticos para garantizar que la RTL producida sea correcta y esté optimizada. Los casos de uso de esta estructura son múltiples. Por ejemplo, la RTL sintetizable producida puede desplegarse en una plataforma FPGA (por ejemplo, Xeon-FPGA) para ejecutar eficientemente el programa de vértices dado. O bien, puede perfeccionarse aún más para producir una implementación ASIC.
Los grafos pueden representarse como matrices de adyacencia, y el procesamiento de grafos puede formularse como operaciones con matrices dispersas. Las Figuras 76a-b muestran un ejemplo de representación de un gráfico como una matriz de adyacencia. Cada no-cero en la matriz representa un borde entre dos nodos del grafo. Por ejemplo, un 1 en la fila 0 columna 2 representa un borde del nodo A al C.
Uno de los modelos más conocidos para describir cálculos sobre datos de grafos es el modelo de programación de vértices. Una implementación soporta la variante del modelo de programación de vértices de la estructura de software Graphmat, que formula los programas de vértices como multiplicación vectorial de matrices dispersas generalizadas (GSPMV). Como se muestra en la Figura 76c, un programa de vértices consiste en los tipos de datos asociados con los bordes/vértices en el grafo (edata/vdata), los mensajes enviados a través de los vértices en el grafo (mdata), y los datos temporales (tdata) (ilustrados en la porción superior del código del programa); y funciones de cálculo sin estado definidas por el usuario que usan API predefinidas que leen y actualizan los datos del grafo (como se ilustra en la porción inferior del código del programa).
La Figura 76d ilustra un código de programa ilustrativo para ejecutar un programa de vértices. Los datos de los bordes se representan como una matriz de adyacencia A (como en la Figura 76b), los datos de los vértices como un vector y, y los mensajes como un vector disperso x. La Figura 76e muestra la formulación GSPMV, en la que las operaciones de multiplica^) y sumar() en SPMV se generalizan mediante PROCESS_MSG() y REDUCE() definidas por el usuario.
Una observación en este punto es que la variante de GSPMV necesaria para ejecutar el programa de vértices realiza una multiplicación orientada a columnas de la matriz dispersa A (es decir, la matriz de adyacencia) contra un vector disperso x (es decir, los mensajes) para producir un vector de salida y (es decir, los datos de los vértices). Esta operación se denomina col_spMspV (descrita anteriormente con respecto al acelerador anterior).
Estructura de diseño. Una implementación de la estructura se muestra en la Figura 77 que incluye un componente de mapeo de plantillas 7711, un componente de validación 7712 y un componente de ajuste automático 7713. Sus entradas son un programa de vértices especificado por el usuario 7701, objetivos de optimización de diseño 7703 (por ejemplo, máximo rendimiento, mínimo área), y restricciones de diseño de hardware objetivo 7702 (por ejemplo, cantidad máxima de RAM en el chip, anchura de la interfaz de memoria). Como entrada opcional para ayudar al ajuste automático, la estructura también acepta las propiedades de los datos del grafo 7704 (por ejemplo, tipo=grafo natural) o una muestra de datos del grafo.
Dadas estas entradas, el componente de mapeo de plantillas 7711 de la estructura mapea el programa de vértices de entrada a una plantilla de arquitectura de acelerador de hardware, y produce una implementación RTL 7705 de la instancia de acelerador optimizada para ejecutar el programa de vértices 7701. El componente de ajuste automático 7713 realiza un ajuste automático 7713 para optimizar la RTL generada para los objetivos de diseño dados, mientras se cumplen las restricciones de diseño de hardware. Además, el componente de validación 7712 valida automáticamente la RTL generada contra los modelos funcionales y de rendimiento derivados de las entradas. Los bancos de pruebas de validación 7706 y los informes de ajuste 7707 se producen junto con la RTL.
Plantilla de arquitectura de hardware de multiplicación vectorial de matriz dispersa generalizada (GSPMV)
Una implementación de una plantilla de arquitectura para GSPMV se muestra en la Figura 77, que se basa en la arquitectura del acelerador descrita anteriormente (véase, por ejemplo, la Figura 74 y el texto asociado). Muchos de los componentes ilustrados en la Figura 77 son personalizables. En una implementación, la arquitectura para soportar la ejecución de programas de vértices se ha ampliado de la siguiente manera.
Como se ilustra en la Figura 78, se proporcionan bloques lógicos personalizables dentro de cada PE para soportar PROCESS_MSG() 1910, REDUCE() 7811, APPLY 7812, y SEND_MSG() 7813 necesarios para el programa de vértices. Además, una implementación proporciona estructuras de almacenamiento personalizables en el chip y una lógica de empaquetado/desempaquetado 7805 para soportar datos de grafos definidos por el usuario (es decir, vdata, edata, mdata, tdata). La unidad de gestión de datos 6905 ilustrada incluye un planificador de PE 7401 (para planificar PE como se ha descrito anteriormente), memorias intermedias auxiliares 7801 para almacenar la columna activa, datos x), una memoria intermedia de lectura 7402, un controlador de memoria 7803 para controlar el acceso a la memoria del sistema, y una memoria intermedia de escritura 7403. Además, en la implementación mostrada en la Figura 78 los vdata y tdata antiguos y nuevos se almacenan dentro de la memoria de PE local 7421. Diversas máquinas de estado de control pueden ser modificadas para soportar la ejecución de programas de vértices, acatando las funcionalidades especificadas por los algoritmos de la Figura 76d y 76e.
La operación de cada pieza del acelerador se resume en la Figura 79. En 7901, el vector y (vdata) se carga en la RAM de PE 7421. En 7902, el vector x y los punteros de columna se cargan en la memoria intermedia auxiliar 7801. En 7903, para cada elemento del vector x, la columna A se envía por flujo continuo (edata) y los PE ejecutan PROC_MSG() 7810 y REDUCE() 7811. En 7904, los PE ejecutan APPLY() 7812. En 7905, los PE ejecutan SEND_MSG() 7813, produciendo mensajes, y la unidad de gestión de datos 6905 los escribe como vectores x en memoria. En 7906, la unidad de gestión de datos 6905 escribe los vectores y actualizados (vdata) almacenados en las RAM de PE 7421 de vuelta a la memoria. Las técnicas anteriores se ajustan al algoritmo de ejecución del programa de vértices mostrado en las Figuras 76d y 76e. Para aumentar el rendimiento, la arquitectura permite aumentar el número de PE en una pieza y/o el número de piezas en el diseño. De este modo, la arquitectura puede aprovechar múltiples niveles de paralelismos en el grafo (es decir, entre subgrafos (entre bloques de la matriz de adyacencia) o dentro de cada subgrafo). La tabla en la Figura 80a resume los parámetros personalizables de una implementación de la plantilla. También es posible asignar parámetros asimétricos entre piezas para su optimización (por ejemplo, una pieza con más PE que otra).
Mapeo, validación y ajuste automáticos
Ajuste. Basándose en las entradas, una implementación de la estructura realiza un ajuste automático para determinar los mejores parámetros de diseño a utilizar para personalizar la plantilla de arquitectura de hardware para optimizarla para el programa de vértices de entrada y (opcionalmente) los datos de grafo. Hay muchas consideraciones de ajuste, que se resumen en la tabla de la Figura 80b. Como se ilustra, estas incluyen la localidad de los datos, el tamaño de los datos del grafo, las funciones de cálculo del grafo, la estructura de los datos del grafo, los atributos de acceso a los datos del grafo, los tipos de datos del grafo y los patrones de los datos del grafo.
Mapeo de plantillas. En esta fase, la estructura toma los parámetros de la plantilla determinados por la fase de ajuste y produce una instancia del acelerador "rellenando" las porciones personalizables de la plantilla. Las funciones de cómputo definidas por el usuario (por ejemplo, la Figura 76c) pueden mapearse desde la especificación de entrada a los bloques de cómputo de PE apropiados usando herramientas de síntesis de alto nivel (HLS) existentes. Las estructuras de almacenamiento (por ejemplo, RAM, memorias intermedias, caché) y las interfaces de memoria se instancian usando sus correspondientes parámetros de diseño. La lógica de empaquetado/desempaquetado puede generarse automáticamente a partir de las especificaciones del tipo de datos (por ejemplo, la Figura 76a). También se generan partes de las máquinas de estado finito (FSM) de control basándose en los parámetros de diseño proporcionados (por ejemplo, esquemas de planificación de PE).
Validación. En una implementación, la instancia de la arquitectura del acelerador (RTL sintetizable) producida por el mapeo de la plantilla se valida automáticamente. Para ello, una implementación de la estructura deriva un modelo funcional del programa de vértices que se usará como referencia "de oro". Se generan bancos de prueba para comparar la ejecución de esta referencia de oro con las simulaciones de la implementación RTL de la instancia de la arquitectura. La estructura también realiza la validación del rendimiento comparando las simulaciones RTL con el modelo de rendimiento analítico y el simulador de software de precisión de ciclo. Informa del desglose del tiempo de ejecución y señala los cuellos de botella del diseño que afectan al rendimiento.
Los cálculos sobre conjuntos de datos dispersos - vectores o matrices cuyos valores son en su mayoría cero - son fundamentales para un número cada vez mayor de aplicaciones de importancia comercial, pero normalmente solo alcanzan un pequeño porcentaje del rendimiento máximo cuando se ejecutan en las CPU actuales. En el ámbito de la informática científica, los cálculos de matrices dispersas han sido durante décadas los núcleos clave de los solucionadores lineales. Más recientemente, el crecimiento explosivo del aprendizaje automático y el análisis de grafos ha llevado los cálculos dispersos a la tendencia principal. Los cálculos de matrices dispersas son fundamentales para muchas aplicaciones de aprendizaje automático y constituyen el núcleo de muchos algoritmos de grafos.
Los cálculos de matrices dispersas tienden a estar limitados por el ancho de banda de la memoria más que por el cálculo, lo que dificulta que los cambios en la CPU mejoren su rendimiento. Ejecutan pocas operaciones por elemento de datos de la matriz y a menudo iteran sobre una matriz entera antes de reutilizar cualquier dato, lo que hace que las cachés sean ineficaces. Además, muchos algoritmos de matrices dispersas contienen un número significativo de recopilaciones y dispersiones dependientes de los datos, tales como la operación result[row] = matrix[row][i].value * vector[matrix[row][i].index] que se encuentra en la multiplicación matriz-vectorial dispersa, que es difícil de predecir y reduce la eficacia de los preajustadores.
Para ofrecer un mejor rendimiento de las matrices dispersas que los microprocesadores convencionales, un sistema debe proporcionar un ancho de banda de memoria significativamente mayor que el de las CPU actuales y una arquitectura de cálculo muy eficiente desde el punto de vista energético. El aumento del ancho de banda de la memoria permite mejorar el rendimiento, pero el elevado coste de energía/bit de los accesos a la DRAM limita la cantidad de energía disponible para procesar ese ancho de banda. Sin una arquitectura de cálculo eficiente desde el punto de vista energético, un sistema podría encontrarse en la situación de no poder procesar los datos de un sistema de memoria de gran ancho de banda sin superar su presupuesto de energía.
Una implementación comprende un acelerador para cálculos de matrices dispersas que utiliza DRAM apilada para proporcionar el ancho de banda que requieren los algoritmos de matrices dispersas, combinado con una arquitectura de cálculo personalizada para procesar ese ancho de banda de forma eficiente desde el punto de vista energético.
VISTA GENERAL DE MATRICES DISPERSAS
Muchas aplicaciones crean conjuntos de datos en los que la gran mayoría de los valores son cero. Los métodos de elementos finitos modelan los objetos como una malla de puntos en la que el estado de cada punto es una función del estado de los puntos cercanos a él en la malla. Matemáticamente, esto se convierte en un sistema de ecuaciones que se representa como una matriz donde cada fila describe el estado de un punto y los valores de la fila son cero para todos los puntos que no afectan directamente al estado del punto que la fila describe. Los grafos pueden representarse como una matriz de adyacencia, donde cada elemento {i,j} de la matriz da el peso del borde entre los vértices i y j del grafo. Dado que la mayoría de los vértices se conectan solo con una pequeña fracción de los demás vértices del grafo, la gran mayoría de los elementos de la matriz de adyacencia son ceros. En el aprendizaje automático, los modelos suelen entrenarse usando conjuntos de datos que consisten en muchas muestras, cada una de las cuales contiene un conjunto de características (observaciones del estado de un sistema u objeto) y la salida deseada del modelo para ese conjunto de características. Es muy común que la mayoría de las muestras solo contengan un pequeño subconjunto de las posibles características, por ejemplo, cuando las características representan diferentes palabras que pueden estar presentes en un documento, creando de nuevo un conjunto de datos donde la mayoría de los valores son cero.
Los conjuntos de datos en los que la mayoría de los valores son cero se denominan "dispersos", y es muy común que los conjuntos de datos dispersos sean extremadamente dispersos, con valores distintos de cero en menos del 1 % de sus elementos. Estos conjuntos de datos suelen representarse como matrices, usando estructuras de datos que solo especifican los valores de los elementos no cero de la matriz. Aunque esto aumenta la cantidad de espacio necesario para representar cada elemento distinto de cero, ya que es necesario especificar tanto la ubicación del elemento como su valor, el ahorro global de espacio (memoria) puede ser sustancial si la matriz es lo suficientemente dispersa. Por ejemplo, una de las representaciones más sencillas de una matriz dispersa es la representación de lista de coordenadas (COO), en la que cada no-cero se especifica mediante una tupla {índice de fila, índice de columna, valor}. Aunque esto triplica la cantidad de almacenamiento necesaria para cada valor distinto de cero, si solo el 1 % de los elementos de una matriz tienen valores distintos de cero, la representación COO ocupará solo el 3 % del espacio que ocuparía una representación densa (que representa el valor de cada elemento de la matriz).
La Figura 81 ilustra uno de los formatos de matriz dispersa más comunes, el formato de almacenamiento de filas comprimido (CRS, en ocasiones abreviado CSR). En formato CRS, la matriz 8100 se describe mediante tres matrices: una matriz de valores 8101, que contiene los valores de los elementos no cero, una matriz de índices 8102, que especifica la posición de cada elemento no cero dentro de su fila de la matriz, y una matriz de inicios de fila 8103, que especifica dónde empieza cada fila de la matriz en las listas de índices y valores. Por tanto, el primer elemento nocero de la segunda fila de la matriz de ejemplo puede encontrarse en la posición 2 de las matrices de índices y valores, y se describe con la tupla {0, 7}, que indica que el elemento se encuentra en la posición 0 dentro de la fila y tiene valor 7. Otros formatos de matriz dispersa comúnmente usados son la columna dispersa comprimida (CSC), que es la columna mayor dual del CRS, y ELLPACK, que representa cada fila de la matriz como una lista de ancho fijo de valores no-cero y sus índices, rellenando con ceros explícitos cuando una fila tiene menos elementos no-cero que la fila más larga de la matriz.
Los cálculos sobre matrices dispersas tienen la misma estructura que sus homólogos de matriz densa, pero la naturaleza de los datos dispersos tiende a hacerlos mucho más intensivos en cuanto a ancho de banda que sus homólogos de matriz densa. Por ejemplo, tanto las variantes dispersas como las densas de la multiplicación matrizmatriz encuentran C = A - B calculando Ci,j = Ai, - B,j para todo i, j. En un cálculo de matriz-matriz denso, esto lleva a una reutilización sustancial de los datos, porque cada elemento de A participa en N operaciones de multiplicaciónadición (suponiendo matrices N x N), al igual que cada elemento de B. Mientras la multiplicación de matriz-matriz esté bloqueada por la localidad de la caché, esta reutilización hace que el cálculo tenga una baja relación bytes/operación y esté limitado por el cálculo. Sin embargo, en la variante dispersa, cada elemento de A solo participa en tantas operaciones de multiplicación y adición como valores distintos de cero haya en la fila correspondiente de B, mientras que cada elemento de B solo participa en tantas operaciones de multiplicación y adición como elementos distintos de cero haya en la columna correspondiente de A. A medida que aumenta la dispersión de las matrices, también lo hace la relación bytes/operación, lo que hace que el rendimiento de muchos cálculos de matrices dispersas se vea limitado por el ancho de banda de la memoria, a pesar de que la multiplicación de matrices densas es uno de los cálculos canónicos de los límites de la computación.
Cuatro operaciones constituyen la mayor parte de los cálculos de matrices dispersas que se ven en las aplicaciones actuales: la multiplicación de vectores densos por matrices dispersas (SpMV), la multiplicación de vectores dispersos por matrices dispersas, la multiplicación de matrices dispersas por matrices dispersas y las operaciones de relajación/suavizado, tal como el suavizado de Gauss-Seidel usado en las implementaciones de la prueba de rendimiento del gradiente conjugado de alto rendimiento. Estas operaciones comparten dos características que hacen que un acelerador de matrices dispersas sea práctico. En primer lugar, están dominadas por los productos escalares vectoriales, lo que hace posible implementar un hardware sencillo que pueda realizar los cuatro cálculos importantes. Por ejemplo, una multiplicación matriz-vector se realiza tomando el producto escalar de cada fila de la matriz con el vector, mientras que una multiplicación matriz-matriz toma el producto escalar de cada fila de una matriz con cada columna de la otra. En segundo lugar, las aplicaciones suelen realizar múltiples cálculos sobre la misma matriz, tal como los miles de multiplicaciones de la misma matriz por diferentes vectores que realiza un algoritmo de máquina de vectores de soporte con el entrenamiento de un modelo. Este uso repetido de la misma matriz hace que resulte práctico transferir matrices a/desde un acelerador durante la ejecución del programa y/o reformatear la matriz de forma que se simplifique la tarea del hardware, ya que el coste de las transferencias/transformaciones de datos puede amortizarse en muchas operaciones sobre cada matriz.
Los cálculos de matrices dispersas suelen alcanzar solo un pequeño porcentaje del rendimiento máximo del sistema en el que se ejecutan. Para demostrar por qué ocurre esto, la Figura 82 muestra las etapas 8201 -8204 implicadas en una implementación de la multiplicación de vectores densos y matrices dispersas utilizando el formato de datos CRS. En primer lugar, en el punto 8201, se lee de la memoria la estructura de datos que representa una fila de la matriz, lo que suele implicar un conjunto de lecturas secuenciales que son fáciles de predecir y precargar. En segundo lugar, en 8202, los índices de los elementos distintos de cero de la fila de la matriz se utilizan para recopilar los elementos correspondientes del vector, lo que requiere una serie de accesos a la memoria dependientes de los datos y difíciles de predecir (una operación de recopilación). Además, estos accesos a la memoria suelen tocar solo una o dos palabras en cada línea de caché referenciada, lo que supone un importante desperdicio de ancho de banda cuando el vector no cabe en la caché.
En tercer lugar, en 8203, el procesador calcula el producto escalar de los elementos distintos de cero de la fila de la matriz y los elementos correspondientes del vector. Finalmente, en 8204, el resultado del producto escalar se escribe en el vector resultado, al que también se accede secuencialmente, y el programa pasa a la siguiente fila de la matriz. Obsérvese que esta es una visión conceptual/algorítmica del cálculo, y que la secuencia exacta de operaciones que ejecuta el programa dependerá de la ISA del procesador y de la anchura del vector.
Este ejemplo ilustra una serie de características importantes del cálculo de matrices dispersas. Suponiendo que los tipos de datos son de 32 bits y que ni la matriz ni el vector caben en la caché, el cálculo del primer elemento de la fila de salida requiere la lectura de 36 bytes de la DRAM, pero solo cinco instrucciones de cálculo (tres multiplicaciones y dos sumas), para una relación bytes/operación de 7,2:1.
Sin embargo, el ancho de banda de la memoria no es el único reto para los cálculos de matrices dispersas de alto rendimiento. Como muestra la Figura 82, los accesos al vector en SpMV dependen de los datos y son difíciles de predecir, exponiendo la latencia de los accesos al vector a la aplicación. Si el vector no cabe en la caché, el rendimiento de SpMV se vuelve sensible a la latencia de la DRAM, así como al ancho de banda, a menos que el procesador proporcione suficiente paralelismo para saturar el ancho de banda de la DRAM, incluso cuando muchos hilos están parados esperando datos.
Por lo tanto, una arquitectura para el cálculo de matrices dispersas debe proporcionar varias cosas para ser eficaz. Debe ofrecer un gran ancho de banda de memoria para satisfacer las necesidades de bytes/operación de los cálculos dispersos. También debe soportar la recopilación de gran ancho de banda de vectores grandes que pueden no caber en la caché. Por último, aunque realizar suficientes operaciones aritméticas por segundo para mantener el ancho de banda de la memoria DRAM no es un reto en sí mismo, la arquitectura debe realizar esas operaciones y todos los accesos a la memoria que requieren de forma eficiente desde el punto de vista energético para mantenerse dentro de los presupuestos de energía del sistema.
Una implementación consiste en un acelerador diseñado para proporcionar las tres características necesarias para un alto rendimiento de las matrices dispersas: un gran ancho de banda de la memoria, un gran ancho de banda en la recopilación de grandes vectores y un cálculo eficiente desde el punto de vista energético. Como se ilustra en la Figura 83, una implementación del acelerador incluye una pastilla de lógica aceleradora 8305 y una o más pilas 8301-8304 de pastillas de DRAM. La DRAM apilada, que se describe con más detalle a continuación, proporciona un gran ancho de banda de memoria con poca energía/bit. Por ejemplo, se espera que las DRAM apiladas ofrezcan entre 256 y 512 GB/segundo a 2,5 pJ/bit, mientras que los DIMM LPDDR4 solo ofrecerán 68 GB/segundo y tendrán un coste energético de 12 pJ/bit.
El chip lógico acelerador 8305, situado en la parte inferior de la pila de aceleradores, está adaptado a las necesidades de los cálculos de matrices dispersas, y puede consumir el ancho de banda ofrecido por una pila de DRAM 8301 -8304 gastando solo 2-4 vatios de potencia, con un consumo de energía proporcional al ancho de banda de la pila. Para ser conservadores, se asume un ancho de banda de la pila de 273 GB/s (el ancho de banda esperado de las pilas WIO3) para el resto de esta solicitud. Los diseños basados en pilas de mayor ancho de banda incorporarían más paralelismo para consumir el ancho de banda de la memoria.
La Figura 84 ilustra una implementación del chip lógico acelerador 8305, orientado desde una perspectiva superior a través de la pila de pastillas DRAM 8301-8304. Los bloques de canales de DRAM apilados 8405 hacia el centro del diagrama representan las vías a través del silicio que conectan el chip lógico 8305 a las DRAM 8301-8304, mientras que los bloques controladores de memoria 7410 contienen la lógica que genera las señales de control para los canales de DRAM. Aunque en la figura se muestran ocho canales de DRAM 8405, el número real de canales implementados en un chip acelerador variará dependiendo de las DRAM apiladas que se usen. La mayoría de las tecnologías DRAM de pila que se están desarrollando ofrecen cuatro u ocho canales.
Los motores de producto escalar (DPE) 8420 son los elementos de cálculo de la arquitectura. En la implementación particular mostrada en las Figuras 84A-B,cada conjunto de ocho DPE está asociado con una caché de vector 8415. La Figura 85 proporciona una visión general de alto nivel de un DPE que contiene dos memorias intermedias 8505­ 8506, dos ALU de multiplicación-adición de 64 bits 8510, y lógica de control 8500. Durante los cálculos, la unidad de control del chip 8500 envía por flujo continuo segmentos de los datos que se están procesando a las memorias intermedias 8505-8506. Una vez que cada memoria intermedia está llena, la lógica de control del DPE se secuencia a través de las memorias intermedias, calculando los productos escalares de los vectores que contienen y escribiendo los resultados en el registro de retención de resultados del DPE 8512, que está conectado en cadena con los registros de retención de resultados de los otros DPE para escribir el resultado de un cálculo de vuelta a la DRAM de pila 8301 -8304.
En una implementación, el chip lógico acelerador funciona a aproximadamente 1 GHz y 0,65 V para minimizar el consumo de energía (aunque la frecuencia y el voltaje de operación particulares pueden modificarse para diferentes aplicaciones). Los análisis basados en los estudios de diseño de 14 nm muestran que las memorias intermedias de 32-64 KB cumplen esta especificación de frecuencia a esa tensión, aunque puede ser necesario una ECC fuerte para evitar los errores de software. La unidad de multiplicación-adición puede funcionar a la mitad de la velocidad de reloj base para cumplir con la sincronización con una tensión de alimentación de 0,65 V y una canalización poco profunda. El hecho de tener dos ALU proporciona un rendimiento de una multiplicación-adición/ciclo de doble precisión por DPE.
Con 273 GB/segundo y una velocidad de reloj de 1,066 MHz, la pila de DRAM 8301-8304 proporciona 256 bytes de datos por ciclo de reloj del chip lógico. Suponiendo que los índices y valores de las matrices son cantidades de al menos 32 bits, esto se traduce en 32 elementos de matriz dispersa por ciclo (4 bytes de índice 4 bytes de valor = 8 bytes/elemento), lo que requiere que el chip realice 32 multiplicaciones-adiciones por ciclo para mantener el ritmo. (Esto es para la multiplicación matriz-vector y supone una alta tasa de aciertos en la caché de vectores, de modo que el 100 % del ancho de banda de la DRAM de la pila se usa para obtener la matriz) Los 64 DPE mostrados en la Figura 84 proporcionan de 2 a 4 veces el rendimiento de cómputo requerido, permitiendo al chip procesar datos al máximo del ancho de banda de la DRAM de la pila incluso si las ALU 8510 no se usan el 100 % del tiempo.
En una implementación, las cachés vectoriales 8415 almacenan en caché los elementos del vector en una multiplicación matriz-vector. Esto aumenta significativamente la eficiencia del esquema de bloqueo de la matriz que se describe a continuación. En una implementación, cada bloque de caché de vector contiene 32-64 KB de caché, para una capacidad total de 256-512 KB en una arquitectura de ocho canales.
La unidad de control del chip 8401 gestiona el flujo de un cómputo y maneja la comunicación con las otras pilas de un acelerador y con otros zócalos del sistema. Para reducir la complejidad y el consumo de energía, los motores de productos escalares nunca solicitan datos de la memoria. En su lugar, la unidad de control del chip 8401 gestiona el sistema de memoria, iniciando transferencias que empujan los bloques de datos apropiados a cada uno de los DPE.
En una implementación, las pilas de un acelerador multipila se comunican entre sí a través de una red de enlaces KTI 8430 que se implementa usando las conexiones vecinas 8431 que se muestran en la figura. El chip también proporciona tres enlaces KTI adicionales que se usan para comunicarse con el otro u otros zócalos en un sistema de múltiples zócalos. En un acelerador multipila, solo estará activo uno de los enlaces KTI fuera de paquete 8430 de las pilas. Las transacciones KTI que se dirigen a la memoria de las otras pilas se dirigirán a la pila correspondiente a través de la red KTI en el paquete.
En el presente documento se describen técnicas y hardware para implementar la multiplicación de matrices dispersas y vectores densos y matrices dispersas y vectores dispersos en una implementación del acelerador. Esto también puede ampliarse para soportar la multiplicación de matrices y matrices, operaciones de relajación y otras funciones para crear un acelerador que soporte operaciones de matrices dispersas.
Mientras que las multiplicaciones matrices y vectores densos y densos y dispersos y densos ejecutan el mismo algoritmo básico (tomando el producto escalar de cada fila de la matriz y el vector), hay diferencias significativas en cómo se implementa este algoritmo cuando el vector es disperso en comparación con cuando es denso, que se resumen en la tabla siguiente.
TABLA
Figure imgf000100_0001
En una multiplicación de matrices dispersas y vectores densos, el tamaño del vector es fijo e igual al número de columnas de la matriz. Dado que muchas de las matrices que se encuentran en los cálculos científicos tienen un promedio de aproximadamente 10 elementos distintos de cero por fila, no es raro que el vector de una multiplicación de matrices dispersas y vectores densos ocupe entre un 5 y un 10 % del espacio que ocupa la propia matriz. Por otra parte, los vectores dispersos suelen ser bastante cortos y contienen un número de valores distintos de cero similar al de las filas de la matriz, lo que facilita su almacenamiento en caché en la memoria del chip.
En una multiplicación de matrices dispersas y vectores densos, la ubicación de cada elemento en el vector viene determinada por su índice, lo que hace factible recopilar los elementos del vector que corresponden a los valores distintos de cero en una región de la matriz y precalcular el conjunto de elementos del vector que hay que recopilar para cualquier vector denso por el que se vaya a multiplicar la matriz. Sin embargo, la ubicación de cada elemento en un vector disperso es imprevisible y depende de la distribución de los elementos distintos de cero en el vector. Esto hace necesario examinar los elementos distintos de cero del vector disperso y de la matriz para determinar qué noceros de la matriz corresponden a valores distintos de cero del vector.
Resulta útil comparar los índices de los elementos distintos de cero de la matriz y el vector, ya que el número de instrucciones/operaciones necesarias para calcular un producto escalar de matriz dispersa y vector disperso es imprevisible y depende de la estructura de la matriz y el vector. Por ejemplo, considérese la posibilidad de tomar el producto escalar de una fila de matriz con un solo elemento distinto de cero y un vector con muchos elementos distintos de cero. Si el no-cero de la fila tiene un índice menor que cualquiera de los no-cero del vector, el producto escalar solo requiere una comparación de índices. Si el no-cero de la fila tiene un índice mayor que cualquiera de los no-cero del vector, el cálculo del producto escalar requiere comparar el índice del no-cero de la fila con cada índice del vector. Esto supone una búsqueda lineal a través del vector, lo cual es una práctica común. Otras búsquedas, tales como la búsqueda binaria, serían más rápidas en el peor de los casos, pero añadirían una sobrecarga significativa en el caso común en el que los no ceros de la fila y el vector se solapan. Por el contrario, el número de operaciones necesarias para realizar una multiplicación de vectores densos por matrices dispersas es fijo y viene determinado por el número de valores distintos de cero en la matriz, lo que facilita la predicción del tiempo necesario para el cálculo.
Debido a estas diferencias, una implementación del acelerador utiliza el mismo algoritmo de alto nivel para implementar la multiplicación matriz dispersa-vector denso y matriz dispersa-vector disperso, con diferencias en cómo se distribuye el vector a través de los motores de producto escalar y cómo se calcula el producto escalar. Dado que el acelerador está pensado para cálculos de matrices dispersas de gran tamaño, no se puede asumir que la matriz o el vector quepan en la memoria del chip. En su lugar, una implementación usa el esquema de bloqueo descrito en la Figura 86.
En particular, en esta implementación, el acelerador dividirá las matrices en bloques de datos de tamaño fijo 8601­ 8602, dimensionados para que quepan en la memoria del chip, y multiplicará las filas del bloque por el vector para generar un segmento del vector de salida antes de pasar al siguiente bloque. Este enfoque plantea dos retos. En primer lugar, el número de no ceros en cada fila de una matriz dispersa varía mucho entre los conjuntos de datos, desde uno hasta 46.000 en los conjuntos de datos estudiados. Esto hace que no sea práctico asignar una o incluso un número fijo de filas a cada motor de producto escalar. Por lo tanto, una implementación asigna segmentos de tamaño fijo de datos de la matriz a cada motor de producto escalar y maneja el caso en el que un segmento contiene múltiples filas de la matriz y el caso en el que una sola fila se divide a través de múltiples segmentos.
El segundo reto es que la búsqueda de todo el vector desde la DRAM de la pila para cada bloque de la matriz tiene el potencial de desperdiciar cantidades significativas de ancho de banda (es decir, la búsqueda de elementos del vector para los que no hay no-ceros correspondientes en el bloque). Esto es particularmente un problema para la multiplicación de matrices dispersas por vectores densos, donde el vector puede ser una fracción significativa del tamaño de la matriz dispersa. Para solucionar esto, una implementación construye una lista de obtención 8611 -8612 para cada bloque 8601-8602 en la matriz, que enumera el conjunto de elementos del vector 8610 que corresponden a valores distintos de cero en el bloque, y solo obtiene esos elementos al procesar el bloque. Aunque las listas de búsqueda también deben obtenerse de la DRAM de la pila, se ha determinado que la lista de obtención para la mayoría de los bloques será una pequeña fracción del tamaño del bloque. También se pueden usar técnicas tales como la codificación de longitud en serie para reducir el tamaño de la lista de obtención.
Por lo tanto, una multiplicación matriz-vector en acelerador implicará la siguiente secuencia de operaciones:
1. Obtener un bloque de datos de la matriz de la pila de la DRAM y distribuirlo entre los motores de productos escalares;
2. Generar una lista de obtención basada en los elementos distintos de cero de los datos de la matriz;
3. Recuperar cada elemento vectorial de la lista de obtención de la pila DRAM y distribuirlo a los motores de producto escalar
4. Calcular el producto escalar de las filas del bloque con el vector y escribir los resultados en la DRAM de la pila; y
5. Paralelamente al cálculo, se obtiene el siguiente bloque de datos de la matriz y se repite hasta que se haya procesado toda la matriz.
Cuando un acelerador contiene múltiples pilas, se pueden asignar estáticamente "particiones" de la matriz a las diferentes pilas y a continuación ejecutar el algoritmo de bloqueo en paralelo en cada partición. Este esquema de bloqueo y difusión tiene la ventaja de que todas las referencias de memoria se originan en una unidad de control central, lo que simplifica enormemente el diseño de la red en el chip, ya que la red no tiene que enrutar solicitudes y respuestas impredecibles entre los motores de producto escalar y los controladores de memoria. También ahorra energía al emitir solo una petición de memoria por cada elemento vectorial que necesita un bloque determinado, en lugar de que los motores de producto escalar individuales emitan solicitudes de memoria para los elementos vectoriales que necesitan para realizar su porción del cálculo. Por último, la obtención de elementos vectoriales a partir de una lista organizada de índices facilita la planificación de las solicitudes de memoria que requieren esas obtenciones de forma que se maximicen los aciertos de página en la DRAM apilada y, por tanto, el uso del ancho de banda.
Uno de los retos de la implementación de la multiplicación de matrices dispersas y vectores densos en las implementaciones del acelerador descritas en el presente documento es hacer coincidir los elementos del vector que se envían por flujo continuo desde la memoria con los índices de los elementos de la matriz en las memorias intermedias de cada motor de producto escalar. En una implementación, 256 bytes (32-64 elementos) del vector llegan al motor de producto escalar por ciclo, y cada elemento del vector podría corresponder a cualquiera de los no ceros en la memoria intermedia de la matriz del motor de producto escalar, ya que los bloques de tamaño fijo de los datos de la matriz fueron traídos a cada memoria intermedia de la matriz del motor de producto escalar.
Realizar tantas comparaciones en cada ciclo sería prohibitivo en cuanto a superficie y energía. En su lugar, una implementación aprovecha el hecho de que muchas aplicaciones de matriz dispersa multiplican repetidamente la misma matriz por el mismo o diferentes vectores y precalculan los elementos de la lista de obtención que cada motor de producto escalar necesitará para procesar su parte de la matriz, usando el formato mostrado en la Figura 87. En el formato básico de CRS, se describe una matriz por una matriz de índices 8702 que definen la posición de cada valor no cero dentro de su fila, una matriz que contiene los valores de cada no cero 8703, y una matriz 8701 que indica dónde comienza cada fila en las matrices de índices y valores. A esto, una implementación añade una matriz de descriptores de bloque 8705 que identifican qué ráfagas de datos vectoriales necesita capturar cada motor de producto escalar para realizar su fracción del cálculo global.
Como se muestra en la Figura 87, cada descriptor de bloque consiste en ocho valores de 16 bits y una lista de descriptores de ráfaga. El primer valor de 16 bits indica al hardware cuántos descriptores de ráfaga hay en el descriptor de bloque, mientras que los siete restantes identifican los puntos de inicio dentro de la lista de descriptores de ráfaga para todos los canales de datos de la DRAM de la pila excepto el primero. El número de estos valores cambiará dependiendo del número de canales de datos que proporcione la DRAM apilada. Cada descriptor de ráfaga contiene un recuento de ráfagas de 24 bits que indica al hardware a qué ráfaga de datos debe prestar atención y un vector de bits de "palabras necesarias" que identifica las palabras dentro de la ráfaga que contienen valores que el motor de procesamiento escalar necesita.
La otra estructura de datos incluida en una implementación es una matriz de índices de memoria intermedia de matriz (MBI) 8704, una MBI por cada no-cero en la matriz. Cada MBI da la posición en la que el elemento vectorial denso que corresponde al no-cero será almacenado en la memoria intermedia de valores vectoriales del motor de producto escalar relevante (véase, por ejemplo, la Figura 89). Cuando se realiza una multiplicación de matriz dispersa y vector denso, los índices de la memoria intermedia de la matriz, en lugar de los índices originales de la matriz, se cargan en la memoria intermedia de índice de la matriz del motor de producto escalar 8704, y sirven como la dirección usada para buscar el valor del vector correspondiente cuando se calcula el producto escalar.
La Figura 88 ilustra cómo funciona esto para una matriz de dos filas que cabe en las memorias intermedias de un solo motor de producto escalar, en un sistema con un solo canal de datos de DRAM apilada y ráfagas de datos de cuatro palabras. La representación original de CRS, que incluye los valores de inicio de fila 8801, los índices de la matriz 8802 y los valores de la matriz 8803 se muestra a la izquierda de la figura. Dado que las dos filas tienen elementos distintos de cero en las columnas {2, 5, 6} y {2, 4, 5}, los elementos 2, 4, 5 y 6 del vector son necesarios para calcular los productos escalares. Los descriptores de bloque lo reflejan, indicando que se requiere la palabra 2 de la primera ráfaga de cuatro palabras (elemento 2 del vector) y las palabras 0, 1 y 2 de la segunda ráfaga de cuatro palabras (elementos 4-6 del vector). Ya que el elemento 2 del vector es la primera palabra del vector que necesita el motor del producto escalar, irá en la ubicación 0 de la memoria intermedia de valores del vector. El elemento 4 del vector irá en la ubicación 1, y así sucesivamente.
Los datos de la matriz de índices de la memoria intermedia de la matriz 8804 contienen la ubicación dentro de la memoria intermedia de valores del vector donde el hardware encontrará el valor que corresponde al no-cero en la matriz. Dado que la primera entrada de la matriz de índices de matriz tiene el valor "2", la primera entrada de la matriz de índices de la memoria intermedia de la matriz obtiene el valor "0", correspondiente a la ubicación donde se almacenará el elemento 2 del vector en la memoria intermedia de valores del vector. Del mismo modo, siempre que aparezca un "4" en la matriz de índices de la matriz, aparecerá un "1" en los índices de la memoria intermedia de la matriz, cada "5" en la matriz de índices de la matriz tendrá su correspondiente "2" en los índices de la memoria intermedia de la matriz, y cada "6" en la matriz de índices de la matriz se corresponderá con un "3" en los índices de la memoria intermedia de la matriz.
Una implementación de la invención realiza los cálculos previos necesarios para soportar los recopiladores rápidos de vectores densos cuando se carga una matriz en el acelerador, aprovechando que el ancho de banda total de un acelerador multipila es mucho mayor que el ancho de banda de los enlaces KTI usados para transferir datos desde la CPU al acelerador. Esta información precalculada aumenta la cantidad de memoria necesaria para mantener una matriz hasta en un 75 %, dependiendo de la frecuencia con la que se produzcan múltiples copias del mismo índice de matriz dentro del segmento de la matriz mapeado en un motor de producto escalar. Sin embargo, puesto que se obtiene la matriz de índices de la memoria intermedia de matrices de 16 bits en lugar de la matriz de índices de la matriz cuando se realiza una multiplicación matriz-vector, la cantidad de datos obtenidos de las DRAM de la pila será a menudo menor que en la representación de CRS original, particularmente para las matrices que usan índices de 64 bits.
La Figura 89 ilustra una implementación del hardware en un motor de producto escalar que usa este formato. Para realizar una multiplicación matriz-vector, los segmentos de la matriz que componen un bloque se copian en la memoria intermedia de índices de la matriz 8903 y en la memoria intermedia de valores de la matriz 8905 (copiando los índices de la memoria intermedia de la matriz en lugar de los índices originales de la matriz), y el descriptor de bloque relevante se copia en la memoria intermedia de descriptor de bloque 8902. A continuación, se usa la lista de obtención para cargar los elementos necesarios del vector denso y difundirlos a los motores de producto escalar. Cada motor de producto escalar cuenta el número de ráfagas de datos vectoriales que pasan por cada canal de datos. Cuando el recuento en un canal de datos determinado coincide con el valor especificado en un descriptor de ráfaga, la lógica de coincidencia 8920 captura las palabras especificadas y las almacena en su memoria intermedia de valores vectoriales 8904.
La Figura 90 muestra el contenido de la unidad de lógica de coincidencia 8920 que realiza esta captura. Un registro de retención 9005 captura el valor en los cables del canal de datos cuando el contador coincide con el valor del descriptor de ráfaga. Un desplazador 9006 extrae las palabras requeridas 9002 de la ráfaga 9001 y las dirige a la ubicación correcta en una memoria intermedia de línea 9007 cuyo tamaño coincide con las filas de la memoria intermedia de valores del vector. Se genera una señal de carga cuando el recuento de ráfagas 9001 es igual a un contador interno 9004. Cuando se llena la memoria intermedia de línea, se almacena en la memoria intermedia de valores vectoriales 9004 (a través del multiplexor 9008). Al ensamblar las palabras de múltiples ráfagas en líneas de esta manera se reduce el número de escrituras/ciclo que la memoria intermedia de valores vectoriales necesita soportar, reduciendo su tamaño.
Una vez que todos los elementos requeridos del vector han sido capturados en la memoria intermedia de valores del vector, el motor de producto escalar calcula el producto o productos escalares requeridos usando las ALU 8910. La lógica de control 8901 recorre la memoria intermedia de índice de la matriz 8903 y la memoria intermedia de valor de la matriz 8904 en secuencia, un elemento por ciclo. La salida de la memoria intermedia de índice de la matriz 8903 se usa como la dirección de lectura para la memoria intermedia de valor del vector 8904 en el siguiente ciclo, mientras que la salida de la memoria intermedia de valor de la matriz 8904 se engancha para que llegue a las ALU 8910 al mismo tiempo que el valor correspondiente de la memoria intermedia de valor del vector 8904. Por ejemplo, usando la matriz de la Figura 88, en el primer ciclo del cálculo del producto escalar, el hardware leería el índice "0" de la memoria intermedia de índice de la matriz 8903 junto con el valor "13" de la memoria intermedia de valor de la matriz 8905. En el segundo ciclo, el valor "0" de la memoria intermedia de índice de la matriz 8903 actúa como dirección para la memoria intermedia de valor del vector 8904, obteniendo el valor del elemento del vector "2", que se multiplica por "13" en el ciclo 3.
Los valores del vector de bits de inicio de fila 8901 indican al hardware cuando termina una fila de la matriz y comienza una nueva. Cuando el hardware llega al final de la fila, coloca el producto escalar acumulado para la fila en su registro de retención de salida 8911 y comienza a acumular el producto escalar para la siguiente fila. Los registros de retención de producto escalar de cada motor de producto escalar están conectados en una cadena que ensambla el vector de salida para la escritura no simultánea.
En la multiplicación de matriz dispersa-vector disperso, el vector tiende a ocupar mucha menos memoria que en la multiplicación matriz dispersa-vector denso, pero, al ser disperso, no es posible obtener directamente el elemento del vector que corresponde a un índice determinado. En su lugar, hay que buscar en el vector, lo que hace poco práctico enrutar solo los elementos que cada motor de producto escalar necesita al motor de producto escalar y hace que la cantidad de tiempo requerida para calcular los productos escalares de los datos de la matriz asignados a cada motor de producto escalar sea impredecible. Debido a esto, la lista de obtención para una multiplicación de matriz dispersa y vector disperso simplemente especifica el índice de los elementos distintos de cero más bajos y más altos en el bloque de la matriz y todos los elementos distintos de cero del vector entre esos puntos deben difundirse a los motores de producto escalar.
La Figura 91 muestra los detalles del diseño de un motor de producto escalar para soportar la multiplicación de matrices dispersas y vectores dispersos. Para procesar un bloque de datos matriciales, los índices (no los índices de la memoria intermedia de la matriz usados en una multiplicación dispersa-densa) y los valores del segmento del motor del producto escalar de la matriz se escriben en las memorias intermedias de índices y valores de la matriz, al igual que los índices y valores de la región del vector necesarios para procesar el bloque. La lógica de control del motor de producto escalar 9140 a continuación hace secuencia a través de las memorias intermedias de índice 9102-9103, que emiten bloques de cuatro índices al comparador 4x49120. El comparador 4x49120 compara cada uno de los índices del vector 9102 con cada uno de los índices de la matriz 9103, y emite las direcciones de la memoria intermedia de cualquier coincidencia a la cola de índices coincidentes 9130. Las salidas de la cola de índices coincidentes 9130 dirigen las entradas de direcciones de lectura de la memoria intermedia de valores matriciales 9105 y de la memoria intermedia de valores vectoriales 9104, que emiten los valores correspondientes a las coincidencias en la ALU de multiplicación-adición 9110. Este hardware permite que el motor de producto escalar consuma al menos cuatro y hasta ocho índices por ciclo siempre que la cola de índices coincidentes 9130 tenga espacio vacío, lo que reduce el tiempo necesario para procesar un bloque de datos cuando las coincidencias de índices son escasas.
Al igual que con el motor de producto escalar de matriz dispersa-vector denso, un vector de bits de inicios de fila 9101 identifica las entradas en las memorias intermedias de matriz 9102-9103 que inician una nueva fila de la matriz. Cuando se encuentra una entrada de este tipo, la lógica de control 9140 se resetea al comienzo de la memoria intermedia de índices vectoriales 9102 y empieza a examinar los índices vectoriales desde su valor más bajo, comparándolos con las salidas de la memoria intermedia de índices matriciales 9103. Del mismo modo, si se alcanza el final del vector, la lógica de control 9140 avanza al comienzo de la siguiente fila en la memoria intermedia de índice de la matriz 9103 y se resetea al comienzo de la memoria intermedia de índice del vector 9102. Una salida de "hecho" informa a la unidad de control del chip cuando el motor de producto escalar ha terminado de procesar un bloque de datos o una región del vector y está listo para pasar al siguiente. Para simplificar una implementación del acelerador, la lógica de control 9140 no pasará al siguiente bloque/región hasta que todos los motores de productos escalares hayan terminado de procesar.
En muchos casos, las memorias intermedias de vectores serán lo suficientemente grandes como para mantener todo el vector disperso que se requiere para procesar el bloque. En una implementación, se proporciona espacio de memoria intermedia para 1.024 o 2.048 elementos de vector, dependiendo de si se usan valores de 32 o 64 bits.
Cuando los elementos necesarios del vector no caben en las memorias intermedias del vector, se puede usar un enfoque de múltiples pasos. La lógica de control 9140 difundirá una memoria intermedia completa del vector a cada motor de producto escalar, que comenzará a iterar a través de las filas en sus memorias intermedias de matriz. Cuando el motor de producto escalar alcanza el final de la memoria intermedia del vector antes de llegar al final de la fila, establecerá un bit en el vector-bit de posición de la fila actual 9111 para indicar dónde debe reanudar el procesamiento de la fila cuando llegue la siguiente región del vector, guardará el producto escalar parcial que ha acumulado en la ubicación de la memoria intermedia de valores de la matriz 9105 correspondiente al inicio de la fila, a menos que el inicio de la fila tenga un valor de índice más alto que cualquiera de los índices del vector que han sido procesados hasta ahora, y avanzará a la siguiente fila. Después de que se hayan procesado todas las filas de la memoria intermedia de la matriz, el motor del producto escalar afirmará su señal de hecho para solicitar la siguiente región del vector, y repetirá el proceso hasta que se haya leído todo el vector.
La Figura 92 ilustra un ejemplo que usa valores específicos. Al inicio del cálculo, un segmento de cuatro elementos de la matriz se ha escrito en las memorias intermedias de la matriz 9103, 9105, y una región de cuatro elementos del vector se ha escrito en las memorias intermedias del vector 9102, 9104. Los vectores de bits de inicio de fila 9101 y de posición de fila actual 9106 tienen ambos el valor "1010", lo que indica que el segmento del motor de producto escalar de la matriz contiene dos filas, una de las cuales comienza en el primer elemento de la memoria intermedia de la matriz, y otra en el tercero.
Cuando se procesa la primera región, la primera fila del segmento ve una coincidencia de índice en el índice 3, calcula el producto de los elementos correspondientes de las memorias intermedias de matriz y vector (4 x 1 = 4) y escribe ese valor en la ubicación de la memoria intermedia de valores de matriz 9105 que corresponde al inicio de la fila. La segunda fila ve una coincidencia de índice en el índice 1, calcula el producto de los elementos correspondientes del vector y la matriz, y escribe el resultado (6) en la memoria intermedia de valores de la matriz 9105 en la posición correspondiente a su inicio. El estado del vector de bits de la posición actual de la fila cambia a "0101", lo que indica que el primer elemento de cada fila ha sido procesado y el cálculo debe reanudarse con los segundos elementos. A continuación, el motor de producto escalar afirma su línea de hecho para señalar que está listo para otra región del vector.
Cuando el motor del producto escalar procesa la segunda región del vector, ve que la fila 1 tiene una coincidencia de índice en el índice 4, calcula el producto de los valores correspondientes de la matriz y el vector (5 x 2 = 10), añade ese valor al producto escalar parcial que se guardó después de procesar la primera región del vector, y emite el resultado (14). La segunda fila encuentra una coincidencia en el índice 7, y emite el resultado 38, como se muestra en la figura. Guardar los productos escalares parciales y el estado del cálculo de esta manera evita el trabajo redundante de procesar elementos de la matriz que no pueden coincidir posiblemente con índices en regiones posteriores del vector (porque el vector se ordena con índices en orden ascendente), sin requerir cantidades significativas de almacenamiento adicional para los productos parciales.
La Figura 93 ilustra cómo se combinan los motores de productos escalares dispersos-densos y dispersos-dispersos anteriormente descritos para obtener un motor de productos escalares que pueda manejar ambos tipos de cálculos. Dada la similitud entre los dos diseños, los únicos cambios requeridos son instanciar tanto la lógica de coincidencia del motor de producto escalar disperso-denso 9311 como el comparador 9320 y la cola de índices coincidentes 9330 del motor de producto escalar disperso-disperso, junto con un conjunto de multiplexores 9350 que determinan qué módulos dirigen las entradas de dirección de lectura y de datos de escritura de las memorias intermedias 9104-9105 y un multiplexor 9351 que selecciona si la salida de la memoria intermedia de valor de la matriz o la salida enganchada de la memoria intermedia de valor de la matriz se envía a las ALU de multiplicación-adición 9110. En una implementación, estos multiplexores son controlados por un bit de configuración en la unidad de control 9140 que se establece al comienzo de una multiplicación matriz-vector y permanece en la misma configuración durante toda la operación.
Una sola pila de aceleradores ofrecerá un rendimiento comparable al de una CPU de servidor en operaciones de matriz dispersa, lo que lo convierte en un acelerador atractivo para teléfonos inteligentes, tabletas y otros dispositivos móviles. Por ejemplo, hay varias propuestas de aplicaciones de aprendizaje automático que entrenan modelos en uno o varios servidores y a continuación los despliegan en dispositivos móviles para procesar los flujos de datos entrantes. Dado que los modelos tienden a ser mucho más pequeños que los conjuntos de datos usados para entrenarlos, la capacidad limitada de una sola pila de aceleradores es una limitación menor en estas aplicaciones, mientras que el rendimiento y la eficiencia energética de los aceleradores permitirán a los dispositivos móviles procesar modelos mucho más complejos de lo que sería factible en sus CPU primarias. Los aceleradores para sistemas no móviles combinarán múltiples pilas para ofrecer un ancho de banda y un rendimiento extremadamente altos.
En las Figuras 94a y 94b se ilustran dos implementaciones de una pila múltiple. Ambas implementaciones integran varias pilas de aceleradores en un paquete que es compatible con las CPU de los servidores actuales. La Figura 94a ilustra una implementación de reemplazo de zócalo con 12 pilas de aceleradores 9401-9412 y la Figura 94b ilustra una implementación de paquete multichip (MCP) con un procesador/conjunto de núcleos 9430 (por ejemplo, un Xeon de bajo número de núcleos) y 8 pilas 9421-9424. Las 12 pilas de aceleradores de la Figura 94a se colocan en una matriz que cabe bajo el disipador de calor de 39 mm x 39 mm usado en los paquetes actuales, mientras que la implementación de la Figura 94b incorpora los ocho pilas y un procesador/conjunto de núcleos dentro del mismo espacio. En una implementación, las dimensiones físicas usadas para las pilas son las de las pilas WIO3 de 8 GB. Otras tecnologías DRAM pueden tener dimensiones diferentes, lo que puede cambiar el número de pilas que caben en un paquete.
Ambas de estas implementaciones proporcionan una comunicación de baja latencia basada en la memoria entre la CPU y los aceleradores a través de enlaces KTI. El diseño de sustitución de zócalos para implementaciones Xeon sustituye a una o más de las CPU en un sistema de múltiples zócalos, y proporciona una capacidad de 96 GB y 3,2 TB/s de ancho de banda de DRAM de pila. El consumo de energía previsto es de 90W, muy dentro del presupuesto de energía de un zócalo Xeon. El enfoque MCP proporciona 64 GB de capacidad y 2,2 TB/s de ancho de banda, al tiempo que consume 60 W de energía en el acelerador. Esto deja 90 W para la CPU, suponiendo un presupuesto de energía de 150 W por zócalo, suficiente para soportar una CPU Xeon de gama media. Si un diseño detallado del paquete permitiera más espacio para la lógica en el paquete, se podrían usar pilas adicionales o una CPU más potente, aunque esto requeriría mecanismos tales como las técnicas de aparcamiento de núcleos que se están investigando para la pieza híbrida Xeon FPGA para mantener el consumo total de energía dentro del presupuesto de energía del paquete.
Ambos diseños pueden implementarse sin requerir intercaladores de silicio u otras técnicas de integración sofisticadas. Los sustratos orgánicos usados en los paquetes actuales permiten aproximadamente 300 señales por cm de perímetro de la pastilla, lo que es suficiente para soportar la red de KTI entre pilas y los enlaces KTI fuera del paquete. Los diseños de DRAM apiladas suelen soportar chips lógicos que consumen ~10 W de energía antes de que la refrigeración se convierta en un problema, lo que supera con creces las estimaciones de 2 W de energía de la pastilla lógica para una pila que proporciona 256 GB/s de ancho de banda. Por último, los paquetes multichip requieren un espacio de 1 -2 mm entre los chips para el cableado, lo que es coherente con los diseños actuales.
Las implementaciones también pueden implementarse en tarjetas PCIe y/o utilizando aceleradores basados en DDR4-T. Suponiendo un límite de potencia de 300 W para una tarjeta PCIe, la tarjeta puede soportar 40 pilas de aceleradores para una capacidad total de 320 GB y un ancho de banda de 11 TB/s. Sin embargo, la larga latencia y el limitado ancho de banda del canal PCIe limitan un acelerador basado en PCIe a grandes problemas que solo requieren una interacción poco frecuente con la CPU.
Como alternativa, las pilas de aceleradores podrían usarse para implementar aceleradores basados en DDR-T DIMM 9501 -9516, como se muestra en la Figura 95. DDR-T es una interfaz de memoria diseñada para ser compatible con los zócalos y placas base DDR4. Usando el mismo formato de patillas y conectores que la DDR4, la DDR-T proporciona una interfaz basada en transacciones 9500 que permite el uso de dispositivos de memoria con diferentes características de temporización. En esta implementación, las pilas del acelerador 9501-9516 actúan como simples memorias cuando no se usan para realizar cálculos.
Un DIMM DDR-T ofrece espacio suficiente para 16 pilas de acelerador, o 32 si se usan ambos lados de la tarjeta, lo que proporciona una capacidad de memoria de 126-256 GB y un ancho de banda total de 4-8 TB/s. Sin embargo, un sistema de este tipo consumiría entre 120 y 240 vatios de energía, mucho más que los ~10 W que consume un DDR4DIMM. Esto requeriría una refrigeración activa, que sería difícil de encajar en el limitado espacio asignado a cada DIMM en una placa base. Aun así, un acelerador basado en DDR-T podría ser atractivo para aplicaciones en las que el usuario no esté dispuesto a renunciar a ningún rendimiento de la CPU por la aceleración y esté dispuesto a pagar el coste de un diseño de placa base personalizado que incluya suficiente espacio entre los módulos DIMM del acelerador para ventiladores u otros sistemas de refrigeración.
En una implementación, las pilas de un acelerador multipila serán nodos KTI separados y distintos, y se gestionarán como dispositivos separados por el software del sistema. El firmware del sistema determinará la tabla de enrutamiento dentro de un acelerador multipila de forma estática en el momento del arranque, basándose en el número de pilas de aceleradores presentes, lo que debería determinar de forma exclusiva la topología.
En una implementación, la interfaz de bajo nivel con el acelerador se implementará usando un software de capa de abstracción del acelerador (AAL), debido a su idoneidad para los aceleradores basados en zócalos. Los aceleradores pueden implementar un agente de caché como se describe en una especificación de interfaz de caché del núcleo (CCI), tratando la DRAM apilada como memoria privada (no coherente) para el acelerador que no es accesible por el sistema anfitrión (es decir, agente de caché configuración de memoria caché privada, tal como CA+PCM). La especificación de la CCI exige un espacio de direcciones de registro de configuración/estado (CSR) independiente para cada acelerador, que se usa por el controlador para controlar el acelerador. De acuerdo con la especificación, cada acelerador comunicará su estado al anfitrión a través de una memoria de estado del dispositivo (DSM), una región de memoria fijada a la memoria del anfitrión que se usa para indicar el estado del acelerador. Por tanto, en un sistema de 12 pilas, habrá 12 regiones DSM distintas gestionadas por un único agente de controlador unificado. Estos mecanismos pueden usarse para crear una memoria intermedia de comandos para cada pila. Una memoria intermedia de comandos es una región de memoria fija mapeada a la memoria del sistema, implementada como una cola circular gestionada por el controlador AAL. El controlador escribe los comandos en la memoria intermedia de comandos de cada pila y cada pila consume elementos de su memoria intermedia de comandos especializada. Por tanto, la producción y el consumo de comandos estarán desvinculados en esta implementación.
Como ejemplo, considérese un sistema compuesto por una sola pila de aceleradores conectada a una CPU de anfitrión. El usuario escribe un código para realizar el siguiente cálculo: wn+1 = wn - aAwn, donde A es una matriz y wx son vectores. La estructura de software y el controlador AAL descomponen este código en la siguiente secuencia de comandos:
TRANSMITIR - cargar una secuencia de particiones (wn+1, wn, a, A) en la memoria caché privada
MULTIPLICAR - multiplicar una secuencia de particiones (tmp = wn * a * A)
RESTAR - restar una secuencia de particiones (wn+1 = wn - tmp)
RECIBIR - almacenar una secuencia de particiones en la memoria del anfitrión que contiene el resultado (wn+1)
Estos comandos operan en "particiones", unidades de datos de grano grueso (aproximadamente 16 MB-512 MB) ubicadas en la memoria caché del anfitrión o privada. Las particiones están pretendidas para mapear fácilmente los bloques de datos que los sistemas de computación distribuida MapReduce o Spark usan para facilitar la aceleración de los cálculos distribuidos usando el acelerador o aceleradores. El controlador AAL es responsable de crear un mapeo estático uno a uno de las particiones a las regiones de memoria de anfitrión o a las pilas del acelerador. Las pilas del acelerador mapean individualmente cada una sus particiones a su espacio de direcciones de memoria caché privada (PCM). Las particiones se describen mediante un índice de partición, que es un identificador único, más (para las particiones ubicadas en la memoria del anfitrión) la región o regiones de memoria correspondientes y el formato de los datos. Las particiones ubicadas en la PCM se gestionan por la unidad de control central, que determina la región de direcciones de la PCM para la partición.
En una implementación, para inicializar la PCM del acelerador, el anfitrión dirige al acelerador para que cargue datos desde la memoria del anfitrión. Una operación TRANSMITIR hace que el acelerador lea la memoria del anfitrión y almacene los datos leídos en la PCM del acelerador. Los datos a transmitir se describen mediante una secuencia de tuplas {índice de partición, región de memoria del anfitrión, formato de datos}. Para evitar la sobrecarga de datos por el controlador del anfitrión, el acelerador puede implementar la memoria virtual compartida (SVM) del protocolo de sistema 2 (SPL2).
El formato de datos de cada tupla describe la disposición de la partición en la memoria. Ejemplos de formatos que soporta el acelerador incluyen la fila dispersa comprimida (CSR) y la matriz densa multidimensional. En el ejemplo anterior, A puede estar en formato CSR mientras que wn puede estar en formato de matriz. La especificación del comando incluye la información necesaria y las direcciones de memoria del anfitrión para dirigir al acelerador a cargar todas las particiones referenciadas por la operación TRANSMITIR en la PCM.
Cada operación puede hacer referencia a un pequeño número de operandos en forma de secuencias de particiones. Por ejemplo, la operación MULTIPLICAR hace que el acelerador lea la DRAM apilada y realice una multiplicación vectorial de la matriz. Por tanto, en este ejemplo tiene cuatro operandos: el vector destino tmp, el multiplicador A, el multiplicando wn y el escalar a. El vector de destino tmp se acumula en una secuencia de particiones especificada por el controlador como parte del comando que contiene la operación. El comando dirigirá el acelerador para inicializar la secuencia de particiones si es necesario.
Una operación RECIBIR hace que el acelerador lea la PCM y escriba en la memoria del anfitrión. Esta operación puede implementarse como un campo opcional en todas las demás operaciones, fusionando potencialmente un comando para realizar una operación tal como MULTIPLICAR con la directiva para almacenar el resultado en la memoria del anfitrión. El operando de destino de la operación RECIBIR se acumula en el chip y a continuación se transmite a una partición en la memoria del anfitrión, que debe fijarse por el controlador antes de despachar el comando (a menos que el acelerador implemente SVM de SPL2 ).
Flujo de despacho de comandos
En una implementación, después de insertar comandos en la memoria intermedia de comandos para una pila, el controlador generará una escritura CSR para notificar a la pila de los nuevos comandos a consumir. La escritura de CSR por el controlador es consumida por la unidad de control central de la pila del acelerador, lo que hace que la unidad de control genere una serie de lecturas en la memoria intermedia de comandos para leer los comandos despacho por el conductor a la pila. Cuando una pila de aceleradores completa un comando, escribe un bit de estado en su DSM. El controlador AAL sondea o monitoriza estos bits de estado para determinar la finalización del comando. La salida de una operación de TRANSMITIR o MULTIPLICAR a la DSM es un bit de estado que indica la finalización. Para una operación de RECIBIR, la salida a la DSM es un bit de estado y una secuencia de particiones escritas en la memoria del anfitrión. El controlador es responsable de identificar la región de memoria que debe escribir el acelerador. La unidad de control de la pila es responsable de generar una secuencia de operaciones de lectura en la DRAM apilada y las correspondientes escrituras en las particiones de destino en la memoria del anfitrión.
Activación de software
En una implementación, los usuarios interactúan con el acelerador o aceleradores llamando a una biblioteca de rutinas para mover datos al acelerador, realizar cálculos de matrices dispersas, etc. La API de esta biblioteca puede ser lo más parecida posible a las bibliotecas de matrices dispersas existentes, para reducir el esfuerzo necesario para modificar las aplicaciones existentes y aprovechar el acelerador o aceleradores. Otra ventaja de una interfaz basada en librerías es que oculta los detalles del acelerador y sus formatos de datos, lo que permite a los programas aprovechar las ventajas de las distintas implementaciones enlazando dinámicamente la versión correcta de la librería en tiempo de ejecución. También se pueden implementar bibliotecas para llamar a los aceleradores desde entornos informáticos distribuidos como Spark.
El área y el consumo de energía de una pila de aceleradores puede estimarse dividiendo el diseño en módulos (memorias, ALU, etc.) y recopilando datos de diseños de 14 nm de estructuras similares. Para escalar a un proceso de 10 nm, se puede suponer una reducción del 50 % del área junto con una reducción del 25 % del Cdyn, y una reducción del 20 % de la potencia de fuga. Las estimaciones de área incluyen todas las memorias en el chip y las ALU. Se supone que los cables pasan por encima de la lógica/memorias. Las estimaciones de energía incluyen la energía activa de las ALU y las memorias, la energía de fuga de las memorias y la energía de los cables en nuestras principales redes. Se asumió una velocidad de reloj base de 1 GHz y una tensión de suministro de 0,65 V en los procesos de 14 nm y 10 nm. Como ya se ha mencionado, las ALU pueden funcionar a la mitad de la velocidad de reloj base, y esto se ha tenido en cuenta en las proyecciones de energía. Se espera que los enlaces KTI y las redes entre pilas estén inactivos o casi inactivos cuando el acelerador esté realizando cálculos, por lo que no se incluyeron en las estimaciones de energía. Una implementación rastrea la actividad en estas redes y las incluye en las estimaciones de energía.
Las estimaciones prevén que un acelerador como el descrito en el presente documento ocupará 17 mm2 de área de chip en un proceso de 14 nm y 8,5 mm2 en un proceso de 10 nm, con la gran mayoría del área del chip ocupada por las memorias. La Figura 96 muestra una disposición potencial de un acelerador destinado a situarse bajo una pila de DRAM WIO3 que incluye 64 motores de productos escalares 8420, 8 cachés vectoriales 8415 y un controlador de memoria integrado 8410. El tamaño y la ubicación de los topes de E/S de la pila de DRAM 9601, 9602 mostrados están especificados por la norma WIO3, y la lógica del acelerador encaja en el espacio entre ellos. Sin embargo, para facilitar el montaje, la pastilla lógica bajo una pila de DRAM debe ser al menos tan grande como la pista de DRAM. Por lo tanto, un chip acelerador real tendría aproximadamente entre 8 y 10 mm, aunque la mayor parte del área no se utilizaría. En una implementación, esta área no utilizada puede usarse para aceleradores para diferentes tipos de aplicaciones con ancho de banda limitado.
La DRAM apilada es una tecnología de memoria que, como su nombre sugiere, apila múltiples pastillas de DRAM en vertical para ofrecer un mayor ancho de banda, una mayor integración física con la pastilla de computación y un menor consumo de energía por bit que los módulos de DRAM tradicionales, como los DIMM DDR4. La tabla de la Figura 97 compara siete tecnologías DRAM: DDR4 y LPDDR4 no apiladas, los módulos Pico, las pilas de alto ancho de banda (HBM2 ) de la norma JEDEC y de E/S ancha (WIO3 ), una DRAM apilada y la RAM desintegrada (DiRAM).
Las DRAM apiladas se presentan en dos diversidades: en la pastilla y al lado de la pastilla. Las pilas en la pastilla 8301-8304, como se ilustra en la Figura 98a, se conectan directamente a una pastilla lógica o SoC 8305 usando vías de silicio. Por el contrario, las pilas al lado de la pastilla 8301 -8304, mostradas en la Figura 98b, se colocan al lado de la pastilla lógica/SoC 8305 en un intercalador o puente de silicio 9802, con las conexiones entre la DRAM y la pastilla lógica pasando por el intercalador 9802 y una capa de interfaz 9801. Las pilas de memoria DRAM en la pastilla tienen la ventaja de que permiten paquetes más pequeños que las pilas al lado de la pastilla, pero tienen la desventaja de que es difícil acoplar más de una pila a una pastilla lógica, lo que limita la cantidad de memoria que pueden proporcionar por pastilla. Por el contrario, el uso de un intercalador de silicio 9802 permite que una pastilla lógica se comunique con múltiples pilas de pastilla al lado, aunque con un cierto coste de área.
Dos características importantes de una DRAM son el ancho de banda por pila y la energía por bit, ya que definen el ancho de banda que cabe en un paquete y la energía necesaria para consumir ese ancho de banda. Estas características hacen que WIO3, ITRI y DiRAM sean las tecnologías más prometedoras para un acelerador como el descrito, ya que los módulos Pico no proporcionan suficiente ancho de banda y la energía/bit de HBM2 aumentaría considerablemente el consumo de energía.
De estas tres tecnologías, la DiRAM tiene el mayor ancho de banda y capacidad, así como la menor latencia, lo que la hace muy atractiva. WIO3 es otra opción prometedora, suponiendo que se convierta en una norma JEDEC, y proporcione un buen ancho de banda y capacidad. La memoria del ITRI es la que menos energía/bit tiene de las tres, lo que permite que quepa más ancho de banda en un presupuesto de energía determinado. También tiene una baja latencia, y su interfaz similar a la SRAM reduciría la complejidad del controlador de memoria del acelerador. Sin embargo, la memoria RAM del ITRI es la de menor capacidad de las tres, ya que su diseño compensa la capacidad por el rendimiento.
El acelerador descrito en el presente documento está diseñado para abordar el análisis de datos y los algoritmos de aprendizaje automático basados en una primitiva de multiplicación vectorial de matriz dispersa (SpMV). Aunque SpMV suele dominar el tiempo de ejecución de estos algoritmos, también son necesarias otras operaciones para implementarlos.
Como ejemplo, considérese el listado de búsqueda de amplitud primero (BFS) mostrado en la Figura 99. En este ejemplo, la mayor parte del trabajo lo realiza la SpMV en la línea 4; sin embargo, también hay una operación de resta vector-vector (línea 8), una operación de producto interno (línea 9) y una operación de mapa de datos en paralelo (línea 6). La resta de vectores y el producto interno son operaciones relativamente sencillas que suelen estar soportadas en las ISA de vectores y necesitan poca explicación.
En cambio, la operación de mapa de datos paralelos es mucho más interesante porque introduce la programabilidad en una operación conceptualmente a nivel de elementos. El ejemplo de BFS demuestra la programabilidad proporcionada por la funcionalidad de mapa de una implementación. En particular, la función Lambda en BFS (véase la línea 6 en la Figura 99) se usa para rastrear cuándo se visitó un vértice por primera vez. Esto se hace en una implementación pasando a la función Lambda dos matrices y un escalar. La primera matriz que se pasa a la función Lambda es la salida de la operación SpMV y refleja los vértices que se pueden alcanzar actualmente. La segunda matriz tiene una entrada para cada vértice cuyo valor es el número de iteración en el que el vértice fue visto por primera vez, o 0 si el vértice aún no ha sido alcanzado. El escalar que se pasa a la función Lambda es simplemente el contador de iteraciones del bucle. En una implementación, la función Lambda se compila en una secuencia de operaciones escalares que se realiza en cada elemento del vector de entrada para generar el vector de salida.
Una representación intermedia (IR) de la secuencia de operaciones para BFS se ilustra en la Figura 99. La IR de Lambda de BFS demuestra varias características interesantes. Se garantiza que el código Lambda generado solo tiene un único bloque básico. Una implementación evita las construcciones iterativas en una función Lambda y realiza la conversión if para evitar el flujo de control. Esta restricción reduce significativamente la complejidad de la estructura de cálculo usada para ejecutar una Lambda, ya que no necesita soportar el flujo de control general.
Todas las operaciones de memoria se realizan al principio del bloque básico (líneas 2 a 4 de la Figura 99). Cuando se transforma a ensamblador, las operaciones de memoria se elevan al preámbulo del codelet (líneas 2 a 5).
Se realizó una evaluación de las estadísticas para las pruebas de rendimiento implementadas con el acelerador que hacen uso de las funciones Lambda. Se registró el número de instrucciones, el número total de registros y el número total de cargas para cuantificar la "complejidad" de diversas funciones Lambda de interés. Además, la longitud de la ruta crítica refleja la cadena más larga de instrucciones dependientes en cada función Lambda. Cuando el número de instrucciones es significativamente mayor que la ruta crítica, las técnicas de paralelismo a nivel de instrucción son una solución aplicable para aumentar el rendimiento. Algunas cargas son invariables para una invocación dada de una llamada de mapa o reducción (todas las ejecuciones de la función Lambda cargarán el mismo valor). Esta situación se denomina "carga invariable Lambda" y se realiza un análisis para detectarla.
Basándose en los resultados analizados, se necesita un almacén de instrucciones relativamente pequeño y un archivo de registros para soportar la ejecución de las funciones Lambda. Las técnicas para aumentar la concurrencia (intercalar la ejecución de múltiples funciones Lambda) aumentan el tamaño y la complejidad del archivo de registro; sin embargo, un diseño de línea de base podría tener tan solo 16 entradas. Además, un archivo de registro 2R1W debería ser suficiente para todas las operaciones si también se proporciona un archivo de registro de predicado de un solo bit para su uso con operaciones de comparación y movimiento condicional.
Como se describe a continuación, las cargas invariantes de Lambda se ejecutarán en los motores de recopilación, de modo que solo se realicen una vez por cada invocación de las funciones Lambda. Los valores devueltos por estas cargas se pasarán al elemento de procesamiento para que puedan ser leídos en el archivo de registro local de la ruta de datos Lambda según sea necesario.
En una implementación, la ejecución de una función Lambda se divide entre los motores de recopilación y los elementos de procesamiento (PE) (por ejemplo, los motores de punto escalar descritos anteriormente) para aprovechar las diferentes capacidades de cada unidad. Las funciones lambda tienen tres tipos de argumentos: constantes, escalares y vectores. Las constantes son argumentos cuyo valor puede determinarse en tiempo de compilación. Los argumentos escalares corresponden a las cargas invariantes de Lambda descritas anteriormente, y son argumentos cuyo valor varía entre las invocaciones de la función Lambda, pero que permanecen constantes en todos los elementos sobre los que opera una función Lambda dada. Los argumentos vectoriales son matrices de datos que la función Lambda procesa, aplicando las instrucciones de la función a cada elemento de los argumentos vectoriales.
En una implementación, una función Lambda se especifica mediante una estructura de datos de descriptor que contiene el código que implementa la función, cualquier constante a la que hace referencia la función y los punteros a sus variables de entrada y salida. Para ejecutar una función Lambda, el controlador de nivel superior envía un comando a uno o más motores de recopilación que especifica el descriptor de la función Lambda y los índices de inicio y fin de las porciones de los argumentos del vector de la función que el motor de recopilación y su PE asociado deben procesar.
Cuando un motor de recopilación recibe un comando para ejecutar una función Lambda, obtiene el descriptor de la función de la memoria y pasa el descriptor a su PE asociado hasta que alcanza a la última sección del descriptor, que contiene las direcciones de los argumentos escalares de la función. A continuación, obtiene de la memoria cada uno de los argumentos escalares de la función, sustituye la dirección de cada argumento en el descriptor por su valor y pasa el descriptor modificado al PE.
Cuando un PE recibe el comienzo del descriptor de la función desde su motor de recopilación, copia las direcciones de las entradas vectoriales de la función en los registros de control, y el hardware de obtención del PE comienza a cargar las páginas de las entradas vectoriales en las memorias intermedias locales del PE. A continuación, decodifica cada una de las instrucciones que implementan la función Lambda y almacena los resultados en una pequeña memoria intermedia de instrucciones decodificadas. A continuación, el PE espera que los valores de los argumentos escalares de la función lleguen desde su motor de recopilación, y que la primera página de cada uno de los argumentos vectoriales de la función llegue desde la memoria. Una vez que los argumentos de la función han llegado, el PE comienza a aplicar la función Lambda a cada elemento en su rango de los vectores de entrada, confiando en el hardware de obtención y escritura no simultánea del PE para obtener páginas de datos de entrada y escribir no simultáneamente páginas de valores de salida según se requiera. Cuando el PE alcanza el final de su rango de datos asignado, señala al controlador de nivel superior que ha terminado y está listo para comenzar otra operación.
La Figura 100 muestra el formato de los descriptores usados para especificar funciones Lambda de acuerdo con una implementación. En particular, la Figura 100 muestra el formato del descriptor Lambda en la memoria 10001 y el descriptor del formato Lambda pasado a un PE 10002. Todos los campos del descriptor, excepto las instrucciones, son valores de 64 bits. Las instrucciones son valores de 32 bits, empaquetados en dos palabras de 64 bits. El descriptor está organizado de tal manera que los argumentos escalares aparecen en último lugar, lo que permite que el motor de recopilación pase todo menos los argumentos escalares al PE antes de que obtenga los argumentos escalares de la memoria. Esto hace posible que el PE decodifique las instrucciones de la función y comience a obtener sus argumentos vectoriales mientras espera que el motor de recopilación obtenga los argumentos escalares. El descriptor de la función Lambda y los argumentos escalares se obtienen a través de las cachés vectoriales para eliminar los accesos redundantes a la DRAM cuando una función Lambda se distribuye a través de múltiples pares motor de recopilación/PE. Como se ilustra, el formato de descriptor Lambda en la memoria 10001 puede incluir un puntero a un argumento escalar 10003 mientras que el motor de recopilación obtiene el valor del argumento escalar 10004 en el formato de descriptor Lambda como se pasa al PE 10002.
En una implementación, la primera palabra de cada descriptor es un encabezado que especifica el significado de cada palabra del descriptor. Como se muestra en la Figura 101, los seis bytes inferiores de la palabra de encabezado especifican el número de argumentos vectoriales de la función Lambda 10101, el número de argumentos constantes 10102, el número de salidas vectoriales y escalares 10103-10104, el número de instrucciones de la función 10105 y el número de argumentos escalares de la función 10106 (ordenados para que coincidan con el lugar en el que aparece cada tipo de dato en el descriptor). El séptimo byte de la palabra de encabezado especifica la posición de la instrucción de inicio de bucle 10107 dentro del código de la función (es decir, la instrucción donde el hardware debe comenzar cada iteración después de la primera). El byte de orden superior de la palabra está sin usar 10108. Las palabras restantes contienen las instrucciones de las funciones, las constantes y las direcciones de entrada y salida, en el orden mostrado en la figura.
No se requiere ningún cambio en la ruta de datos del motor de recopilación para soportar las funciones Lambda, ya que todas las operaciones necesarias pueden soportarse modificando la lógica de control. Cuando el motor de recopilación obtiene un descriptor Lambda de la memoria, copiará las líneas del descriptor en las memorias intermedias de línea de los elementos del vector y en la memoria intermedia del descriptor de columna. Las líneas de descriptores que no contengan las direcciones de los argumentos escalares se pasarán al PE sin modificar, mientras que las que sí las contengan permanecerán en las memorias intermedias de las líneas hasta que los valores de los argumentos escalares se obtengan de la memoria y se inserten en las memorias intermedias de las líneas en lugar de sus direcciones. El hardware existente de la memoria intermedia de recopilación y respuesta pendiente puede soportar esta operación sin cambios.
Cambios en el elemento de procesamiento para soportar las funciones Lambda
En una implementación, para soportar funciones Lambda, se agrega una ruta de datos separada al PE, como se ilustra en la Figura 102, que muestra la memoria intermedia de valores matriciales 9105, la memoria intermedia de índices matriciales 9103 y la memoria intermedia de valores vectoriales 9104 descritas anteriormente. Aunque las memorias intermedias del PE siguen siendo las mismas, sus nombres se han cambiado a memoria intermedia de entrada 1, memoria intermedia de entrada 2 y memoria intermedia de entrada 3 para reflejar sus usos más generales en la presente implementación. La ruta de datos de SpMV 9110 también permanece sin cambios respecto a la arquitectura base. Aunque sería posible implementar SpMV como una función Lambda, la construcción del hardware especializado 10201 reduce la potencia y mejora el rendimiento de SpMV. Los resultados de la ruta de datos de SpMV 9110 y de la ruta de datos Lambda 10201 se envían a la memoria intermedia de salida 10202 y finalmente a la memoria del sistema.
La Figura 103 ilustra los detalles de una implementación de la ruta de datos Lambda, que incluye un archivo de registro de predicado 10301, un archivo de registro 10302, lógica de decodificación 10303, una memoria intermedia de instrucciones decodificadas 10305, y que se centra alrededor de una canalización de ejecución en orden 10304 que implementa una ISA de carga-almacén. Si una canalización de ejecución de una sola emisión no proporciona suficiente rendimiento, se puede aprovechar el paralelismo de datos inherente a las operaciones Lambda y vectorizar la canalización de ejecución para procesar múltiples elementos vectoriales en paralelo, lo que debería ser una forma más eficiente de energía para mejorar el paralelismo que aprovechar ILP en funciones Lambda individuales. La canalización de ejecución lee sus entradas y escribe los resultados de vuelta a un archivo de registro de 16-32 entradas 10302, con 64 bits por registro. El hardware no distingue entre registros de enteros y de coma flotante, y cualquier registro puede contener datos de cualquier tipo. El archivo de registro de predicado 10301 contiene la salida de las operaciones de comparación, que se usan para predicar la ejecución de instrucciones. En una implementación, la ruta de datos Lambda 10304 no soporta instrucciones de ramal, por lo que cualquier ejecución condicional debe realizarse a través de instrucciones predicadas.
Al comienzo de cada función Lambda, el motor de recopilación coloca las instrucciones de la función en la memoria intermedia de entrada 3 9104 (la memoria intermedia de valores vectoriales). La lógica de decodificación 10303 decodifica a continuación cada instrucción en secuencia, colocando los resultados en una memoria intermedia de instrucciones decodificadas de 32 entradas 10305. Esto ahorra el coste energético de decodificar repetidamente cada instrucción en cada iteración del bucle1.
La ruta de datos Lambda contiene cuatro registros de control especiales 10306. El registro del contador de índices contiene el índice de los elementos del vector que la ruta de datos Lambda está procesando actualmente, y se incrementa automáticamente al final de cada iteración de la Lambda. El registro de último índice contiene el índice del último elemento del vector que se espera que el PE procese. El registro de inicio del bucle contiene la ubicación en la memoria intermedia de instrucciones decodificadas de la primera instrucción en la porción repetida de la función Lambda, mientras que el registro de fin de bucle contiene la ubicación de la última instrucción en la función Lambda.
La ejecución de una función Lambda comienza con la primera instrucción de la memoria intermedia de instrucciones decodificadas y continúa hasta que la canalización alcance la instrucción señalada por el registro de fin de bucle. En ese punto, la canalización compara el valor del registro del contador de índices con el valor del registro del último índice y realiza una ramificación implícita hacia la instrucción apuntada por el registro de inicio del bucle si el contador de índices es menor que el último índice. Dado que el registro del contador de índices solo se incrementa al final de cada iteración, esta comprobación puede realizarse con antelación para evitar burbujas en la canalización.
Este esquema facilita la inclusión de instrucciones de "preámbulo" que solo deben ejecutarse en la primera iteración de una función Lambda. Por ejemplo, una función Lambda con dos entradas escalares y una constante podría comenzar con tres instrucciones de carga para obtener los valores de esas entradas en el archivo de registro y establecer el registro de inicio del bucle para que apunte a la cuarta instrucción en la memoria intermedia de instrucciones decodificadas, de modo que las entradas solo se lean una vez en lugar de en cada iteración de la función.
En una implementación, la ruta de datos Lambda ejecuta una ISA de carga-almacén similar a la de muchos procesadores RISC. Las instrucciones de carga y almacén de la ruta de datos Lambda hacen referencia a ubicaciones en las memorias intermedias SRAM del PE. Todas las transferencias de datos entre las memorias intermedias de la SRAM y la DRAM se gestionan por el hardware de obtención y escritura no simultánea del PE. La ruta de datos Lambda soporta dos tipos de instrucciones de carga: escalar y elemento. Las cargas escalares obtienen el contenido de la ubicación especificada en una de las memorias intermedias de la SRAM y lo colocan en un registro. Se espera que la mayoría de las instrucciones de carga escalar en una función Lambda se produzcan en el preámbulo de la función, aunque la presión de los registros puede requerir ocasionalmente que las cargas escalares se coloquen en los cuerpos de los bucles.
Las cargas de elementos obtienen elementos de los vectores de entrada de la función Lambda. El PE mantendrá un puntero de cálculo para cada memoria intermedia que apunta al elemento actual del primer vector de entrada que se mapea en esa memoria intermedia. Las cargas de elementos especifican una memoria intermedia objetivo y un desplazamiento desde el puntero de cálculo. Cuando se ejecuta una instrucción de elemento, el hardware añade el desplazamiento especificado al valor del puntero de cómputo módulo el tamaño de la memoria intermedia apropiada, y carga los datos de esa ubicación en un registro. Las instrucciones de almacén de elementos son similares, pero escriben los datos en la dirección apropiada en la memoria intermedia de salida 10202 del PE.
Este enfoque permite soportar múltiples vectores de entrada y salida con el hardware de obtención existente del PE. Los vectores de entrada se alternan entre las memorias intermedias de entrada 1 9105 y 2 9103 en el orden especificado por el descriptor de la función Lambda, y el hardware de obtención lee páginas enteras de cada vector en las memorias intermedias a la vez.
Como ejemplo, considérese una función que tiene tres vectores de entrada, A, B, y C. El vector de entrada A se mapeará en la memoria intermedia de entrada 19105 del PE en un desplazamiento de 0. La entrada B se mapeará a la memoria intermedia de entrada 29103, de nuevo con un desplazamiento de 0. La entrada C se mapeará en la memoria intermedia de entrada 19105, con un desplazamiento de 256 (asumiendo páginas de 256 bytes al estilo Tezzaron). El hardware de obtención del PE intercalará páginas de las entradas A y C en la memoria intermedia de entrada 19105, mientras que la memoria intermedia de entrada 29103 se llenará con páginas de la entrada B. Cada iteración de la función Lambda obtendrá el elemento apropiado de la entrada A ejecutando una carga de elementos de la memoria intermedia 19105 con un desplazamiento de 0, obtendrá el elemento apropiado de la entrada B con una carga de elementos de la memoria intermedia 29103 con un desplazamiento de 0, y obtendrá su elemento de la entrada C con una carga de elementos de la memoria intermedia 19105 con un desplazamiento de 256. Al final de cada iteración, el hardware incrementará el puntero de cálculo para avanzar al siguiente elemento de cada vector de entrada. Cuando el puntero de cómputo llega al final de una página, el hardware lo incrementará en (tamaño de página * (n.° de entradas de vector mapeadas en la página -1)) byte para avanzarlo al primer elemento de la siguiente página del primer vector de entrada de la memoria intermedia. Se usará un esquema similar para manejar las funciones Lambda que generan múltiples vectores de salida.
Como se ilustra en la Figura 104, en una implementación, 8 bits están especializados al código de operación 10401. Los 24 bits restantes se dividen entre un único destino 10402 y 3 operandos de entrada 10403-10405, lo que da como resultado especificadores de registro de 6 bits. Como las instrucciones de flujo de control no se usan en una implementación y las constantes se obtienen de un archivo de registro auxiliar, no se requieren acrobacias de asignación de bits para encajar un grande inmediato en una palabra de instrucción. En una implementación, todas las instrucciones encajan en la codificación de instrucciones presentada en la Figura 104. Las codificaciones para un conjunto particular de instrucciones se ilustran en la Figura 105.
En una implementación, las instrucciones de comparación usan un predicado de comparación. Las codificaciones de predicados de comparación ilustrativas se enumeran en la tabla de la Figura 106.
Como se ha detallado anteriormente, en algunos casos es ventajoso usar un acelerador para una determinada tarea. Sin embargo, puede haber casos en los que eso no sea factible y/o ventajoso. Por ejemplo, que un acelerador no esté disponible, que el movimiento de datos al acelerador de como resultado una penalización demasiado grande, que la velocidad del acelerador sea menor que la de un núcleo de procesador, etc. Como tal, en algunas implementaciones, las instrucciones adicionales pueden proporcionar rendimiento y/o eficiencia energética para algunas tareas.
Un ejemplo de multiplicación de matrices se ilustra en la Figura 109. La multiplicación de matrices es C[filasA,colsB] = A[filasA,comm]*B[comm,colsB]. Como se usa en el presente documento con respecto a una instrucción MADD (instrucción de multiplicación-adición), una instrucción de multiplicación matriz*vector se define estableciendo colsB=1. Esta instrucción toma una matriz de entrada A, un vector de entrada B y produce un vector de salida C. En el contexto de los vectores de 512 bits, filasA=8 para doble precisión y 16 para precisión sencilla.
La mayoría de las CPU realizan la multiplicación de matrices densas mediante instrucciones SIMD que operan sobre vectores unidimensionales. Se detalla en el presente documento una instrucción (y el hardware subyacente) que extiende el enfoque SIMD para incluir matrices bidimensionales (piezas) de tamaños 8*4, 8*8, y mayores. Mediante el uso de esta instrucción, se puede multiplicar una pequeña matriz con un vector y añadir el resultado al vector de destino. Todas las operaciones se realizan en una instrucción, lo que amortiza los costes energéticos de la obtención de la instrucción y los datos en un gran número de multiplicaciones-adiciones. Además, algunas implementaciones utilizan un árbol binario para realizar la suma (reducción) y/o incluyen un archivo de registro incrustado en una matriz multiplicadora para mantener una matriz de entrada como una colección de registros.
Con respecto a la multiplicación de matrices, una ejecución de realizaciones de la instrucción MADD computa:
para (i=0; i<N; i++) // N=8 tamaño del elemento de datos empaquetado (por ejemplo, longitud del vector) de las filasA (por ejemplo,
8)
para (k=0; k<M; k++) // comm=M
C[i] = A[i,k]*B[k];
Típicamente, el operando "A" se almacena en ocho registros de datos empaquetados. El operando "B" puede almacenarse en un registro de datos empaquetado o leerse de la memoria. El operando "C" se almacena en un registro de datos empaquetado.
En el resto del análisis de esta instrucción, se analiza una versión "octoMADD". Esta versión multiplica 8 fuentes de elementos de datos empaquetados (por ejemplo, 8 registros de datos empaquetados) por una fuente de elementos de datos empaquetados (por ejemplo, un solo registro). La ampliación del bucle interior proporciona la ejecución para una implementación secuencial (para una instrucción octoMADD):
para (i=0; i<8; i++) C[i] = A[i,0]*B[0]
A[i,1]*B[1]
A[i,2]*B[2]
A[i,3]*B[3]
A[i,4]*B[4]
A[i,5]*B[5]
a [í,6]*b [6]
A[i,7]*B[7];
Como se muestra, cada multiplicación de un elemento de datos empaquetados desde las correspondientes posiciones de elementos de datos empaquetados de los operandos "A" y "B" es seguida por una adición. Las adiciones secuenciales se descomponen en múltiples operaciones más sencillas con un almacenamiento temporal mínimo.
En algunas implementaciones, se usa un enfoque de árbol binario. Un árbol binario minimiza la latencia sumando dos subárboles en paralelo y sumando a continuación los resultados juntos. Esto se aplica recursivamente a todo el árbol binario. El resultado final se añade al operando de destino "C".
La ampliación del bucle interno proporciona la siguiente ejecución para una implementación binaria (para una instrucción octoMADD):
para (i=0; i<8; i++)
C[i] = ((A[i,0]*B[0] A[i,1]*B[1])
(A[i,2]*B[2] A[i,3]*B[3]))
((A[i,4]*B[4] A[i,5]*B[5])
(A[i,6]*B[6] A[i,7]*B[7]));
La Figura 110 ilustra una operación de instrucción octoMADD con la red de reducción del árbol binario. La Figura muestra un carril vectorial de la operación. Con vectores de 512 bits, octoMADD de doble precisión tiene ocho carriles, mientras que octoMADD de precisión sencilla tiene 16 carriles.
Como se ilustra, una pluralidad de circuitos de multiplicación 11001-11015 que realizan las multiplicaciones de A[i,0]*B[0], A[i,1]*B[1], A[i,2]*B[2], A[i,3]*B[3], A[i,4]*B[4], A[i,5]*B[5], A[i,6]*B[6], and A[i,7]*B[7] respectivamente. En este ejemplo, i es el registro A. Típicamente, las multiplicaciones se realizan en paralelo.
Acoplados a los circuitos de multiplicación 11001-11015 están los circuitos de suma 11017-11023 que suman los resultados de los circuitos de multiplicación 11001-11015. Por ejemplo, los circuitos de suma realizan A[i,0]*B[0] A[i,1]*B[1], A[i,2]*B[2] A[i,3]*B[3], A[i,4]*B[4] A[i,5]*B[5], and A[i,6]*B[6] A[i,7]*B[7]. Típicamente, las sumas se realizan en paralelo.
Los resultados de las sumas iniciales se suman usando el circuito de suma 11025 y se suman juntos. El resultado de esta adición se añade por el circuito de suma 11027 al valor original (antiguo) 11031 del destino para generar un nuevo valor 11033 que será almacenado en el destino.
En la mayoría de las implementaciones, una instrucción no puede especificar ocho registros de origen independientes, más un registro u operando de memoria para el otro origen y un registro destino. Por tanto, en algunos casos, la instrucción octoMADD especifica un rango limitado de ocho registros para el operando matriz. Por ejemplo, el operando de la matriz octoMADD puede ser los registros 0-7. En algunas realizaciones, se especifica un primer registro y los registros consecutivos al primer registro son los registros adicionales (por ejemplo, 7).
La Figura 111 ilustra una realización de un método realizado por un procesador para procesar una de multiplicaciónadición.
En 11101, se obtiene una instrucción. Por ejemplo, se obtiene una instrucción de multiplicación-adición. La instrucción de multiplicación-adición incluye un código de operación, un campo para un primer operando de datos empaquetados (ya sea una memoria o un registro), uno o más campos para los operandos de origen de datos empaquetados del segundo a N, y un operando de destino de datos empaquetados. En algunas realizaciones, la instrucción de multiplicación-adición incluye un operando de máscara de escritura. En algunas realizaciones, la instrucción se obtiene de una caché de instrucciones.
La instrucción obtenida se decodifica en 11103. Por ejemplo, la instrucción de multiplicación-adición obtenida se decodifica por unos circuitos de decodificación tales como los que se detallan en el presente documento.
Los valores de datos asociados con los operandos de origen de la instrucción decodificada se recuperan en 11105. Para evitar la necesidad de leer estos valores repetidamente desde el archivo de registro principal cuando se ejecuta una secuencia de instrucciones de multiplicación-adición, se incorpora una copia de estos registros en la propia matriz del multiplicador-sumador (como se detalla a continuación). La copia se mantiene como una caché del archivo de registro principal.
En 11107, la instrucción decodificada se ejecuta por circuitos de ejecución (hardware) tales como los que se detallan en el presente documento, para, para cada posición de elemento de datos empaquetados de los operandos de origen de datos empaquetados del segundo a N, 1) multiplicar un elemento de datos de esa posición de elemento de datos empaquetados de ese operando de origen por un elemento de datos de una posición de elemento de datos empaquetados correspondiente del primer operando de origen para generar un resultado temporal, 2) sumar los resultados temporales, 3) añadir la suma de los resultados temporales a un elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados, y 4) almacenar la suma de los resultados temporales a un elemento de datos de la posición de elemento de datos empaquetados correspondiente del destino en la posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados. N se indica típicamente mediante el código de operación o un prefijo. Por ejemplo, para octoMADD, N es 9 (de manera que hay 8 registros para A). Las multiplicaciones pueden realizarse en paralelo.
En algunas realizaciones, la instrucción se confirma o se retira en 11109.
La Figura 112 ilustra una realización de un método realizado por un procesador para procesar una de multiplicaciónadición.
En 11201, se obtiene una instrucción. Por ejemplo, se obtiene una instrucción de multiplicación-adición. La instrucción de multiplicación-adición fusionada incluye un código de operación, un campo para un primer operando de datos empaquetados (ya sea una memoria o un registro), uno o más campos para los operandos de origen de datos empaquetados del segundo a N, y un operando de destino de datos empaquetados. En algunas realizaciones, la instrucción de multiplicación-adición fusionada incluye un operando de máscara de escritura. En algunas realizaciones, la instrucción se obtiene de una caché de instrucciones.
La instrucción obtenida se decodifica en 11203. Por ejemplo, la instrucción de multiplicación-adición obtenida se decodifica por unos circuitos de decodificación tales como los que se detallan en el presente documento.
Los valores de datos asociados con los operandos de origen de la instrucción decodificada se recuperan en 11205. Para evitar la necesidad de leer estos valores repetidamente desde el archivo de registro principal cuando se ejecuta una secuencia de instrucciones de multiplicación-adición, se incorpora una copia de estos registros en la propia matriz del multiplicador-sumador (como se detalla a continuación). La copia se mantiene como una caché del archivo de registro principal.
En 11207, la instrucción decodificada se ejecuta por circuitos de ejecución (hardware) tales como los que se detallan en el presente documento, para, para cada posición de elemento de datos empaquetados de los operandos de origen de datos empaquetados del segundo a N, 1) multiplicar un elemento de datos de esa posición de elemento de datos empaquetados de ese operando de origen por un elemento de datos de una posición de elemento de datos empaquetados correspondiente del primer operando de origen para generar un resultado temporal, 2) sumar los resultados temporales en pares, 3) añadir la suma de los resultados temporales a un elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados, y 4) almacenar la suma de los resultados temporales a un elemento de datos de la posición de elemento de datos empaquetados correspondiente del destino en la posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados. N se indica típicamente mediante el código de operación o un prefijo. Por ejemplo, para octoMADD, N es 9 (de manera que hay 8 registros para A). Las multiplicaciones pueden realizarse en paralelo.
En algunas realizaciones, la instrucción se confirma o se retira en 11209.
En algunas implementaciones, cuando se encuentra por primera vez una instrucción MADD, un cambiador de nombre sincroniza la copia en caché con el archivo de registro principal inyectando microoperaciones para copiar los registros principales en la caché. Las instrucciones MADD posteriores siguen usando las copias en caché mientras no se modifiquen. Algunas implementaciones anticipan el uso del rango limitado de registros por la instrucción octomadd y difunden escrituras tanto en el archivo de registro principal como en la copia almacenada en caché en el momento en que se producen los valores de registro.
Las Figuras 113A-C ilustran un hardware ilustrativo para realizar una instrucción MADD. La Figura 113A muestra los componentes para ejecutar una instrucción MADD. La Figura 113B muestra un subconjunto de estos componentes. En particular, se usa una pluralidad de circuitos de multiplicación 11323 para multiplicar los elementos de datos empaquetados de los registros de origen con cada circuito de multiplicación 11323 acoplado a un circuito de suma 11327. Cada circuito sumador alimenta al circuito de suma 11327 de forma encadenada. Un selector 11321 se usa para seleccionar entre una entrada externa o una realimentación de un circuito de suma. Un archivo de registro está incrustado dentro de la matriz de multiplicación-adición como parte de un archivo de registro y un multiplexor de lectura 11325. Los registros específicos están conectados a cada columna de multiplicadores-agregadores.
La Figura 113B muestra un archivo de registro y un multiplexor de lectura 11325. El archivo de registro 11327 es una pluralidad de registros para almacenar A como caché (por ejemplo, 4 u 8 registros). El registro correcto se selecciona mediante el multiplexor de lectura 11329.
Un uso esperado de la instrucción octomadd es el siguiente:
// calcular C = A*B
// A se carga como una pieza de 8*8 en REG0-7
// B se carga como una pieza de 1 *8 de la memoria
// C se carga y almacena como una pieza de 24*8 en REG 8-31
para (bucle externo) {
cargar [24,8] piezas de la matriz C en REG 8-31//24 cargas
para (bucle medio) {
cargar [8,8] piezas de la matriz A en REG 0-7 // 8 cargas
para (bucle interno) {
// 24 iteraciones
REG [8-31 del bucle interno] = REG 0-7 * memoria[bucle interno];
// 1 carga
}
}
almacenar [24,8] pieza de la matriz C de REG8-31 // 24 almacenes
}
El bucle interno contiene 24 instrucciones octomadd. Cada una de ellos lee un operando "B" de la memoria y suma a uno de los 24 acumuladores "C". El bucle medio carga los 8 registros "A" con una nueva pieza. El bucle exterior carga y almacena los 24 acumuladores "C". El bucle interno puede desenrollarse y añadirse la precarga para lograr una alta utilización (>90 %) del hardware de octomadd.
En las figuras a continuación se detallan arquitecturas y sistemas ilustrativos para implementar realizaciones de lo anterior. En particular, se describen aspectos (por ejemplo, registros, canalizaciones, etc.) de los tipos de núcleos mencionados anteriormente (como los de fuera de orden, escalares, SIMD). Además, se muestran implementaciones de sistemas y sistemas en un chip que incluyen coprocesadores (por ejemplo, aceleradores, núcleos). En algunas realizaciones, uno o más componentes de hardware y/o instrucciones descritas anteriormente se emulan como se detalla a continuación, o se implementan como módulos de software.
Arquitectura de registro ilustrativa
La Figura 125 es un diagrama de bloques de una arquitectura de registro 12500 de acuerdo con una realización de la invención. En la realización ilustrada, hay 32 registros vectoriales 12510 que tienen una anchura de 512 bits; estos registros se referencian como zmm0 a zmm31. Los 256 bits de orden inferior de los 16 registros zmm inferiores se superponen sobre los registros ymm0-16. Los 128 bits de orden inferior de los 16 registros zmm inferiores (los 128 bits de orden inferior de los registros ymm) se superponen sobre los registros xmm0-15. El formato de instrucción apto para vectores de carácter específico QAC00 opera sobre estos archivos de registro superpuestos, como se ilustra en las tablas a continuación.
Figure imgf000115_0001
En otras palabras, el campo de longitud de vector QAB59B selecciona entre una longitud máxima y una o más longitudes más cortas, donde cada una de estas longitudes más cortas es la mitad de la longitud anterior; y las plantillas de instrucciones sin el campo de longitud de vector QAB59B operan sobre la longitud de vector máxima. Además, en una realización, las plantillas de instrucción de clase B del formato de instrucción apto para vectores de carácter específico QAC00 operan sobre datos de coma flotante de precisión simple/doble escalares o empaquetados y datos enteros escalares o empaquetados. Las operaciones escalares son operaciones realizadas sobre la posición de elemento de datos del orden más bajo en un registro zmm/ymm/xmm; las posiciones de elemento de datos de orden superior o bien se dejan igual que como estaban antes de la instrucción o bien se ponen a cero dependiendo de la realización.
Registros de máscara de escritura 12515 - en la realización ilustrada, hay 8 registros de máscara de escritura (de k0 a k7), cada uno de un tamaño de 64 bits. En una realización alternativa, los registros de máscara de escritura 12515 tienen un tamaño de 16 bits. Como se ha descrito previamente, en una realización de la invención, el registro de máscara de vector k0 no se puede usar como una máscara de escritura; cuando la codificación que normalmente indicaría k0 se usa para una máscara de escritura, este selecciona una máscara de escritura cableada físicamente de 0xFFFF, desactivando en la práctica el enmascaramiento de escritura para esa instrucción.
Registros de propósito general 12525 - en la realización ilustrada, hay dieciséis registros de propósito general de 64 bits que se usan junto con los modos de direccionamiento x86 existentes para direccionar operandos de memoria. A estos registros se hace referencia mediante los nombres RAX, RBX, Rc X, RDX, RBP, RSI, RDI, RSP y de R8 a R15.
Archivo de registro de pila de coma flotante escalar (pila de x87) 12545, en el que se establece un alias para el archivo de registro plano de entero empaquetado MMX 12550 - en la realización ilustrada, la pila de x87 es una pila de ocho elementos usada para realizar operaciones de coma flotante escalar sobre datos de coma flotante de 32/64/80 bits usando la ampliación del conjunto de instrucciones de x87; mientras que los registros MMX se usan para realizar operaciones sobre datos enteros empaquetados de 64 bits, así como para contener operandos para algunas operaciones realizadas entre los registros MMX y XMM.
Realizaciones alternativas de la invención pueden usar registros más anchos o más estrechos. Adicionalmente, realizaciones alternativas de la invención pueden usar más, menos o diferentes archivos de registro y registros.
Arquitecturas de núcleo, procesadores y arquitecturas de ordenador ilustrativas
Los núcleos de procesador se pueden implementar de diferentes formas, para diferentes fines y en diferentes procesadores. Por ejemplo, las implementaciones de tales núcleos pueden incluir: 1) un núcleo en orden de propósito general destinado a computación de propósito general; 2) un núcleo fuera de orden de propósito general de alto rendimiento destinado a computación de propósito general; 3) un núcleo de propósito especial destinado principalmente a gráficos y/o computación científica (de capacidad de proceso). Las implementaciones de diferentes procesadores pueden incluir: 1) una CPU que incluye uno o más núcleos en orden de propósito general destinados a computación de propósito general y/o uno o más núcleos fuera de orden de propósito general destinados a computación de propósito general; y 2) un coprocesador que incluye uno o más núcleos de propósito especial destinados principalmente a cálculos gráficos y/o científicos (de capacidad de proceso). Tales procesadores diferentes conducen a diferentes arquitecturas de sistema informático, que pueden incluir: 1) el coprocesador en un chip separado de la CPU; 2) el coprocesador en una pastilla separada en el mismo paquete que una CPU; 3) el coprocesador en la misma pastilla que una CPU (en cuyo caso, un coprocesador de este tipo se denomina, a veces, lógica de propósito especial, tal como gráficos integrados y/o lógica científica (de capacidad de proceso), o como núcleos de propósito especial); y 4) un sistema en un chip que puede incluir, en la misma pastilla, la CPU descrita (denominada, a veces, el núcleo o núcleos de aplicación o procesador o procesadores de aplicación), el coprocesador descrito anteriormente y una funcionalidad adicional. A continuación, se describen arquitecturas de núcleo ilustrativas, seguidas de descripciones de procesadores y arquitecturas de ordenador ilustrativas.
Arquitecturas de núcleo ilustrativas
Diagrama de bloques de núcleo en orden y fuera de orden
La Figura 126A es un diagrama de bloques que ilustra tanto una canalización en orden ilustrativa como una canalización de cambio de nombre de registro, emisión/ejecución fuera de orden ilustrativa de acuerdo con realizaciones de la invención. La Figura 126B es un diagrama de bloques que ilustra tanto una realización ilustrativa de un núcleo de arquitectura en orden como un núcleo de arquitectura de cambio de nombre de registro, emisión/ejecución fuera de orden ilustrativo a incluir en un procesador de acuerdo con realizaciones de la invención. Los recuadros con líneas de trazo continuo en las Figuras 126A-B ilustran la canalización en orden y el núcleo en orden, mientras que la adición opcional de los recuadros con líneas de trazo discontinuo ilustra la canalización y el núcleo de cambio de nombre de registro, emisión/ejecución fuera de orden. Debido a que el aspecto en orden es un subconjunto del aspecto fuera de orden, se describirá el aspecto fuera de orden.
En la Figura 126A, una canalización de procesador 12600 incluye una etapa de obtención 12602, una etapa de decodificación de longitud 12604, una etapa de decodificación 12606, una etapa de asignación 12608, una etapa de cambio de nombre 12610, una etapa de planificación (también conocida como despacho o emisión) 12612, una etapa de lectura de registro/lectura de memoria 12614, una etapa de ejecución 12616, una etapa de escritura no simultánea/escritura en memoria 12618, una etapa de manejo de excepciones 12622 y una etapa de confirmación 12624.
La Figura 126B muestra el núcleo de procesador 12690 que incluye una unidad de extremo frontal 12630 acoplada a una unidad de motor de ejecución 12650, y ambas se acoplan a una unidad de memoria 12670. El núcleo 12690 puede ser un núcleo de informática de conjunto de instrucciones reducido (RISC), un núcleo de informática de conjunto de instrucciones complejo (CISC), un núcleo de palabras de instrucción muy largas (VLIW) o un tipo de núcleo híbrido o alternativo. Como otra opción más, el núcleo 12690 puede ser un núcleo de propósito especial, tal como, por ejemplo, un núcleo de red o de comunicación, un motor de compresión, un núcleo de coprocesador, un núcleo de unidad de procesamiento de gráficos informáticos de propósito general (GPGPU), un núcleo de gráficos o similares.
La unidad de extremo frontal 12630 incluye una unidad de predicción de ramal 12632 acoplada a una unidad de memoria caché de instrucciones 12634, que se acopla a una memoria intermedia de traducción adelantada (TLB) de instrucciones 12636, que se acopla a una unidad de obtención de instrucciones 12638, que se acopla a una unidad de decodificación 12640. La unidad de decodificación 12640 (o decodificador) puede decodificar instrucciones y generar como una salida una o más microoperaciones, puntos de entrada de microcódigo, microinstrucciones, otras instrucciones u otras señales de control, que se decodifican a partir de, o que reflejan de otro modo, o se derivan de, las instrucciones originales. La unidad de decodificación 12640 se puede implementar usando diversos mecanismos diferentes. Ejemplos de mecanismos adecuados incluyen, pero sin limitación, tablas de búsqueda, implementaciones de hardware, matrices lógicas programables (PLA), memorias de solo lectura de microcódigo (ROM), etc. En una realización, el núcleo 12690 incluye una ROM de microcódigo u otro medio que almacena microcódigo para ciertas macroinstrucciones (por ejemplo, en la unidad de decodificación 12640 o de otra manera dentro de la unidad de extremo frontal 12630). La unidad de decodificación 12640 se acopla a una unidad de cambio de nombre/asignación 12652 en la unidad de motor de ejecución 12650.
La unidad de motor de ejecución 12650 incluye la unidad de cambio de nombre/asignación 12652 acoplada a una unidad de retiro 12654 y un conjunto de una unidad o más unidades de planificador 12656. La unidad o unidades del planificador 12656 representan cualquier número de planificadores diferentes, incluyendo estaciones de reserva, ventana de instrucción central, etc. La unidad o unidades del planificador 12656 están acopladas a la unidad o unidades de archivo o archivos de registro físico 12658. Cada una de las unidades de archivo o archivos de registro físico 12658 representa uno o más archivos de registro físico, diferentes de los cuales almacenan uno o más tipos de datos diferentes, tales como entero escalar, coma flotante escalar, entero empaquetado, coma flotante empaquetado, entero vectorial, coma flotante vectorial, estado (por ejemplo, un puntero de instrucción que es la dirección de la siguiente instrucción que va a ejecutarse), etc. En una realización, la unidad de archivo o archivos de registro físico 12658 comprende una unidad de registros vectoriales, una unidad de registros de máscara de escritura y una unidad de registros escalares. Estas unidades de registro pueden proporcionar registros vectoriales arquitectónicos, registros de máscara de vector y registros de propósito general. La unidad o unidades de archivo o archivos de registro físico 12658 son solapadas por la unidad de retiro 12654 para ilustrar diversas formas en las que se pueden implementar un cambio de nombre de registro y una ejecución fuera de orden (por ejemplo, usando una memoria intermedia o memorias intermedias de reordenación y un archivo o archivos de registro de retiro; usando un archivo o archivos futuros, una memoria o memorias de historial y un archivo o archivos de registro de retiro; usando mapeos de registro y una agrupación de registros; etc.). La unidad de retiro 12654 y la unidad o unidades de archivo o archivos de registro físico 12658 se acoplan a la agrupación o agrupaciones de ejecución 12660. La agrupación o agrupaciones de ejecución 12660 incluye un conjunto de una o más unidades de ejecución 12662 y un conjunto de una o más unidades de acceso a memoria 12664. Las unidades de ejecución 12662 pueden realizar diversas operaciones (por ejemplo, desplazamientos, suma, resta, multiplicación) y sobre diversos tipos de datos (por ejemplo, coma flotante escalar, entero empaquetado, coma flotante empaquetada, entero vectorial, coma flotante vectorial). Aunque algunas realizaciones pueden incluir un número de unidades de ejecución dedicadas a funciones o conjuntos de funciones específicos, otras realizaciones pueden incluir solo una unidad de ejecución o múltiples unidades de ejecución que realizan, todas ellas, todas las funciones. La unidad o unidades de planificador 12656, la unidad o unidades de archivo o archivos de registro físico 12658 y la agrupación o agrupaciones de ejecución 12660 se muestran como que son posiblemente una pluralidad debido a que ciertas realizaciones crean canalizaciones separadas para ciertos tipos de datos/operaciones (por ejemplo, una canalización de entero escalar, una canalización de coma flotante escalar/entero empaquetado/coma flotante empaquetada/entero vectorial/coma flotante vectorial y/o una canalización de acceso a memoria que tienen, cada una, sus propias unidad de planificador, unidad de archivo o archivos de registro físico y/o agrupación de ejecución - y, en el caso de una canalización de acceso a memoria separada, se implementan ciertas realizaciones en las que solo la agrupación de ejecución de esta canalización tiene la unidad o unidades de acceso a memoria 12664). También se debería entender que, cuando se usan canalizaciones separadas, una o más de estas canalizaciones pueden ser de emisión/ejecución fuera de orden y, el resto, en orden.
El conjunto de unidades de acceso a memoria 12664 se acopla a la unidad de memoria 12670, que incluye una unidad de TLB de datos 12672 acoplada a una unidad de memoria caché de datos 12674 acoplada a una unidad de memoria caché de nivel 2 (L2) 12676. En una realización ilustrativa, las unidades de acceso a memoria 12664 pueden incluir una unidad de carga, una unidad de dirección de almacenamiento y una unidad de datos de almacenamiento, cada una de las cuales se acopla a la unidad de TLB de datos 12672 en la unidad de memoria 12670. La unidad de memoria caché de instrucciones 12634 se acopla adicionalmente a una unidad de memoria caché de nivel 2 (L2) 12676 en la unidad de memoria 12670. La unidad de memoria caché de L212676 se acopla a otros uno o más niveles de memoria caché y, finalmente, a una memoria principal.
A modo de ejemplo, la arquitectura de núcleo de cambio de nombre de registro, emisión/ejecución fuera de orden ilustrativa puede implementar la canalización 12600 como sigue: 1) la obtención de instrucciones 12638 realiza las etapas de obtención y de decodificación de longitud 12602 y 12604; 2) la unidad de decodificación 12640 realiza la etapa de decodificación 12606; 3) la unidad de cambio de nombre/asignación 12652 realiza la etapa de asignación 12608 y la etapa de cambio de nombre 12610; 4) la unidad o unidades de planificador 12656 realizan la etapa de planificación 12612; 5) la unidad o unidades de archivo o archivos de registro físico 12658 y la unidad de memoria 12670 realizan la etapa de lectura de registro/lectura de memoria 12614; la agrupación de ejecución 12660 realiza la etapa de ejecución 12616; 6) la unidad de memoria 12670 y la unidad o unidades de archivo o archivos de registro físico 12658 realizan la etapa de escritura no simultánea/escritura en memoria 12618; 7) diversas unidades pueden estar implicadas en la etapa de manejo de excepciones 12622; y 8) la unidad de retiro 12654 y la unidad o unidades de archivo o archivos de registro físico 12658 realizan la etapa de confirmación 12624.
El núcleo 12690 puede soportar uno o más conjuntos de instrucciones (por ejemplo, el conjunto de instrucciones x86 (con algunas ampliaciones que se han añadido con versiones más nuevas); el conjunto de instrucciones MIPS de MIPS Technologies de Sunnyvale, CA; el conjunto de instrucciones ARM (con ampliaciones adicionales opcionales tales como NEON) de ARM Holdings de Sunnyvale, CA), incluyendo la instrucción o instrucciones descritas en el presente documento. En una realización, el núcleo 12690 incluye lógica para soportar una ampliación de conjunto de instrucciones de datos empaquetados (por ejemplo, AVX1, AVX2), permitiendo de ese modo que las operaciones usadas por muchas aplicaciones multimedios se realicen usando datos empaquetados.
Se debería entender que el núcleo puede soportar multiproceso (ejecutar dos o más conjuntos paralelos de operaciones o subprocesos), y puede hacer esto de una diversidad de formas, incluyendo multiproceso segmentado en el tiempo, multiproceso simultáneo (en donde un único núcleo físico proporciona un núcleo lógico para cada uno de los subprocesos para los que ese núcleo físico está sometiendo a multiproceso simultáneamente), o una combinación de los mismos (por ejemplo, obtención y decodificación segmentadas en el tiempo y multiproceso simultáneo a continuación de lo anterior, tal como en la tecnología Hyperthreading de Intel®).
Aunque el cambio de nombre de registros se describe en el contexto de una ejecución fuera de orden, se debería entender que el cambio de nombre de registros se puede usar en una arquitectura en orden. Aunque la realización ilustrada del procesador también incluye unidades de memoria caché de instrucciones y de datos 12634/12674 separadas y una unidad de memoria caché de L212676 compartida, realizaciones alternativas pueden tener una única memoria caché interna tanto para instrucciones como para datos, tal como, por ejemplo, una memoria caché interna de nivel 1 (L1) o múltiples niveles de memoria caché interna. En algunas realizaciones, el sistema puede incluir una combinación de una memoria caché interna y una memoria caché externa que es externa al núcleo y/o al procesador. Como alternativa, toda la memoria caché puede ser externa al núcleo y/o al procesador.
Arquitectura de núcleo en orden ilustrativa específica
Las Figuras 127A-B ilustran un diagrama de bloques de una arquitectura de núcleo en orden ilustrativa más específica, cuyo núcleo sería uno de varios bloques lógicos (incluyendo otros núcleos del mismo tipo y/o de diferentes tipos) en un chip. Los bloques lógicos se comunican a través de una red de interconexión de alto ancho de banda (por ejemplo, una red en anillo) con alguna lógica de función fija, interfaces de E/S de memoria y otra lógica de E/S necesaria, dependiendo de la aplicación.
La Figura 127A es un diagrama de bloques de un único núcleo de procesador, junto con su conexión a la red de interconexión integrada en pastilla 12702 y con su subconjunto local de la memoria caché de nivel 2 (L2) 12704, de acuerdo con realizaciones de la invención. En una realización, un decodificador de instrucciones 12700 soporta el conjunto de instrucciones x86 con una ampliación de conjunto de instrucciones de datos empaquetados. Una memoria caché de L1 12706 permite accesos de latencia baja a memoria caché a las unidades de escalares y de vectores. Aunque en una realización (para simplificar el diseño), una unidad de escalares 12708 y una unidad vectorial 12710 usan conjuntos de registros separados (respectivamente, los registros escalares 12712 y los registros vectoriales 12714) y los datos transferidos entre los mismos se escriben en memoria y entonces se vuelven a leer desde una memoria caché de nivel 1 (L1) 12706, realizaciones alternativas de la invención pueden usar un enfoque diferente (por ejemplo, usar un único conjunto de registros o incluir una ruta de comunicación que permita que se transfieran datos entre los dos archivos de registro sin que se escriban y se vuelvan a leer).
El subconjunto local de la memoria caché de L212704 es parte de una memoria caché de L2 global que se divide en subconjuntos locales separados, uno por núcleo de procesador. Cada núcleo de procesador tiene una ruta de acceso directo a su propio subconjunto local de la memoria caché de L212704. Los datos leídos por un núcleo de procesador se almacenan en su subconjunto de memoria caché de L2 12704 y se puede acceder a los mismos rápidamente, en paralelo con que otros núcleos de procesador accedan a sus propios subconjuntos de memoria caché de L2 locales. Los datos escritos por un núcleo de procesador se almacenan en su propio subconjunto de memoria caché de L2 12704 y se descargan de otros subconjuntos, si es necesario. La red en anillo asegura una coherencia para datos compartidos. La red en anillo es bidireccional para permitir que agentes tales como núcleos de procesador, memorias caché de L2 y otros bloques lógicos se comuniquen entre sí dentro del chip. Cada ruta de datos de anillo tiene 1012 bits de anchura por dirección.
La Figura 127B es una vista ampliada de parte del núcleo de procesador en la Figura 127A de acuerdo con realizaciones de la invención. La Figura 127B incluye una memoria caché de datos de L1 12706A parte de la memoria caché de L1 12704, así como más detalles con respecto a la unidad vectorial 12710 y los registros vectoriales 12714. Específicamente, la unidad vectorial 12710 es una unidad de procesamiento de vectores (VPU) de anchura 16 (véase la ALU 12728 de anchura 16), que ejecuta una o más de instrucciones de números enteros, flotantes de precisión simple y flotantes de precisión doble. La VPU soporta la alineación de las entradas de registro con la unidad de alineación 12720, la conversión numérica con las unidades de conversión numérica 12722A-B y la replicación con la unidad de replicación 12724 en la entrada de memoria. Los registros de máscara de escritura 12726 permiten predicar escrituras vectoriales resultantes.
La Figura 128 es un diagrama de bloques de un procesador 12800 que puede tener más de un núcleo, puede tener un controlador de memoria integrado y puede tener gráficos integrados de acuerdo con realizaciones de la invención. Los recuadros con líneas de trazo continuo en la Figura 128 ilustran un procesador 12800 con un único núcleo 12802A, un agente de sistema 12810, un conjunto de una o más unidades de controlador de bus 12816, mientras que la adición opcional de los recuadros con líneas de trazo discontinuo ilustra un procesador 12800 alternativo con múltiples núcleos 12802A-N, un conjunto de una unidad o más unidades de controlador de memoria integrado 12814 en la unidad de agente de sistema 12810 y la lógica de propósito especial 12808.
Por lo tanto, diferentes implementaciones del procesador 12800 pueden incluir: 1) una CPU con la lógica de propósito especial 12808 que es una lógica de gráficos y/o científica (de rendimiento) integrada (que puede incluir uno o más núcleos), y los núcleos 12802A-N que son uno o más núcleos de propósito general (por ejemplo, núcleos en orden de propósito general, núcleos fuera de orden de propósito general, una combinación de los dos); 2) un coprocesador con los núcleos 12802A-N que son un gran número de núcleos de propósito especial destinados principalmente a cálculos gráficos y/o científicos (de rendimiento); y 3) un coprocesador con los núcleos 12802A-N que son un gran número de núcleos en orden de propósito general. Por lo tanto, el procesador 12800 puede ser un procesador de propósito general, un coprocesador o un procesador de propósito especial, tal como, por ejemplo, un procesador de red o de comunicación, un motor de compresión, un procesador de gráficos, una GPGPU (unidad de procesamiento de gráficos de propósito general), un coprocesador de muchos núcleos integrados (MIC) de capacidad de proceso alta (que incluye 30 o más núcleos), un procesador integrado o similar. El procesador se puede implementar en uno o más chips. El procesador 12800 puede ser parte de y/o se puede implementar sobre uno o más sustratos usando cualquiera de un número de tecnologías de proceso, tales como, por ejemplo, BiCMOS, CMOS o NMOS.
La jerarquía de memoria incluye uno o más niveles de memoria caché dentro de los núcleos, un conjunto o una o más unidades de memoria caché compartidas 12806 y memoria externa (no mostrada) acoplada al conjunto de unidades de controlador de memoria integrado 12814. El conjunto de unidades de memoria caché compartidas 12806 puede incluir una o más memorias caché de nivel medio, tales como de nivel 2 (L2), de nivel 3 (L3), de nivel 4 (L4) o de otros niveles de memoria caché, una memoria caché de último nivel (LLC) y/o combinaciones de las mismas. Aunque, en una realización, una unidad de interconexión basada en anillo 12812 interconecta la lógica de gráficos integrados 12808 (la lógica de gráficos integrados 12808 es un ejemplo y también se denomina en el presente documento lógica de propósito especial), el conjunto de unidades de memoria caché compartidas 12806 y la unidad de agente de sistema 12810/unidad o unidades de controlador de memoria integrado 12814, realizaciones alternativas pueden usar cualquier número de técnicas bien conocidas para interconectar tales unidades. En una realización, se mantiene la coherencia entre una o más unidades de memoria caché 12806 y los núcleos 12802-A-N.
En algunas realizaciones, uno o más de los núcleos 12802A-N son capaces de múltiples hilos. El agente del sistema 12810 incluye aquellos componentes que coordinan y operan los núcleos 12802A-N. La unidad de agente del sistema 12810 puede incluir, por ejemplo, una unidad de control de potencia (PCU) y una unidad de visualización. La PCU puede ser o incluir una lógica y unos componentes necesarios para regular el estado de alimentación de los núcleos 12802A-N y la lógica de gráficos integrada 12808. La unidad de visualización es para accionar uno o más visualizadores conectados externamente.
Los núcleos 12802A-N pueden ser homogéneos o heterogéneos en términos del conjunto de instrucciones de arquitectura; es decir, dos o más de los núcleos 12802A-N pueden ejecutar el mismo conjunto de instrucciones, mientras que otros pueden ejecutar solo un subconjunto de ese conjunto de instrucciones o un conjunto de instrucciones diferente.
Arquitecturas de ordenador ilustrativas
Las Figuras 129-132 son diagramas de bloques de arquitecturas de ordenador ilustrativas. También son adecuados otros diseños y configuraciones de sistema conocidos en las técnicas para portátiles, equipos de sobremesa, PC portátiles, asistentes digitales personales, estaciones de trabajo para ingeniería, servidores, dispositivos de red, concentradores de red, conmutadores, procesadores integrados, procesadores de señales digitales (DSP), dispositivos de gráficos, dispositivos de videojuegos, decodificadores de salón, microcontroladores, teléfonos celulares, reproductores de medios portátiles, dispositivos de mano y diversos otros dispositivos electrónicos. En general, son generalmente adecuados una enorme diversidad de sistemas o dispositivos electrónicos capaces de incorporar un procesador y/u otra lógica de ejecución como se divulga en el presente documento.
Haciendo referencia a continuación a la Figura 129, se muestra un diagrama de bloques 12900 de un sistema de acuerdo con una realización de la presente invención. El sistema 12900 puede incluir uno o más procesadores 12910, 12915, que se acoplan a un concentrador de controlador 12920. En una realización, el concentrador de controlador 12920 incluye un concentrador de controlador de memoria de gráficos (GMCH) 12990 y un concentrador de entrada/salida (IOH) 12950 (que pueden estar en chips separados); el GMCH 12990 incluye controladores de memoria y de gráficos a los que se acoplan la memoria 12940 y un coprocesador 12945; el IOH 12950 acopla los dispositivos de entrada/salida (E/S) 12960 al GMCH 12990. Como alternativa, uno o ambos de los controladores de memoria y de gráficos están integrados dentro del procesador (como se describe en el presente documento), la memoria 12940 y el coprocesador 12945 se acoplan directamente al procesador 12910, y el concentrador de controlador 12920 en un único chip con el IOH 12950.
La naturaleza opcional de los procesadores adicionales 12915 se indica en la Figura 129 con líneas de trazo discontinuo. Cada procesador 12910, 12915 puede incluir uno o más de los núcleos de procesamiento descritos en el presente documento y puede ser alguna versión del procesador 12800.
La memoria 12940 puede ser, por ejemplo, una memoria de acceso aleatorio dinámica (DRAM), una memoria de cambio de fase (PCM) o una combinación de las dos. Para al menos una realización, el concentrador de controlador 12920 se comunica con el procesador o procesadores 12910, 12915 a través de un bus multipunto, tal como un bus de lado frontal (FSB), una interfaz de punto a punto tal como la interconexión de ruta rápida (QuickPath Interconnect ((QPI)) o una conexión similar 12995.
En una realización, el coprocesador 12945 es un procesador de propósito especial, tal como, por ejemplo, un procesador de MIC de capacidad de proceso alta, un procesador de red o de comunicación, un motor de compresión, un procesador de gráficos, una GPGPU, un procesador integrado o similar. En una realización, el concentrador de controlador 12920 puede incluir un acelerador de gráficos integrado.
Puede haber una diversidad de diferencias entre los recursos físicos 12910, 12915 en términos de un espectro de métricas de méritos que incluyen características arquitectónicas, microarquitectónicas, térmicas, de consumo de energía y similares.
En una realización, el procesador 12910 ejecuta instrucciones que controlan operaciones de procesamiento de datos de un tipo general. Puede haber instrucciones de coprocesador integradas dentro de las instrucciones. El procesador 12910 reconoce estas instrucciones de coprocesador como de un tipo que debería ser ejecutado por el coprocesador 12945 adjunto. En consecuencia, el procesador 12910 emite estas instrucciones de coprocesador (o señales de control que representan instrucciones de coprocesador) en un bus del coprocesador u otra interconexión, al coprocesador 12945. Los coprocesadores 12945 aceptan y ejecutan las instrucciones de coprocesador recibidas.
Haciendo referencia a continuación a la Figura 130, se muestra un diagrama de bloques de un primer sistema 13000 ilustrativo más específico de acuerdo con una realización de la presente invención. Como se muestra en la Figura 130, el sistema de múltiples procesadores 13000 es un sistema de interconexión de punto a punto e incluye un primer procesador 13070 y un segundo procesador 13080 acoplados a través de una interconexión de punto a punto 13050. Cada uno de los procesadores 13070 y 13080 puede ser alguna versión del procesador 12800. En una realización de la invención, los procesadores 13070 y 13080 son, respectivamente, los procesadores 12910 y 12915, mientras que el coprocesador 13038 es el coprocesador 12945. En otra realización, los procesadores 13070 y 13080 son, respectivamente, el procesador 12910 y el coprocesador 12945.
Los procesadores 13070 y 13080 se muestran incluyendo las unidades de controlador de memoria integrado (IMC) 13072 y 13082, respectivamente. El procesador 13070 también incluye, como parte de sus unidades de controlador de bus, las interfaces de punto a punto (P-P) 13076 y 13078; de forma similar, el segundo procesador 13080 incluye las interfaces P-P 13086 y 13088. Los procesadores 13070, 13080 pueden intercambiar información a través de una interfaz de punto a punto (P-P) 13050 usando los circuitos de interfaz P-P 13078, 13088. Como se muestra en la Figura 130, los IMC 13072 y 13082 acoplan los procesadores a unas memorias respectivas, en concreto, una memoria 13032 y una memoria 13034, que pueden ser porciones de una memoria principal unidas localmente a los procesadores respectivos.
Cada uno de los procesadores 13070, 13080 puede intercambiar información con un conjunto de chips 13090 a través de las interfaces P-P 13052, 13054 individuales usando los circuitos de interfaz de punto a punto 13076, 13094, 13086, 13098. El conjunto de chips 13090 puede opcionalmente intercambiar información con el coprocesador 13038 a través de una interfaz de alto rendimiento 13092. En una realización, el coprocesador 13038 es un procesador de propósito especial, tal como, por ejemplo, un procesador de MIC de capacidad de proceso alta, un procesador de red o de comunicación, un motor de compresión, un procesador de gráficos, una GPGPU, un procesador integrado o similar.
Se puede incluir una memoria caché compartida (no mostrada) en uno cualquiera del procesador o fuera de ambos procesadores, pero conectada con los procesadores a través de una interconexión P-P, de tal forma que la información de memoria caché local de uno cualquiera de los procesadores, o de ambos, se puede almacenar en la memoria caché compartida si un procesador se coloca en un modo de bajo consumo.
El conjunto de chips 13090 se puede acoplar a un primer bus 13016 a través de una interfaz 13096. En una realización, el primer bus 13016 puede ser un bus de interconexión de componentes periféricos (PCI), o un bus tal como un bus PCI Express u otro bus de interconexión de E/S de tercera generación, aunque el alcance de la presente invención no se limita a ello.
Como se muestra en la Figura 130, diversos dispositivos de E/S 13014 se pueden acoplar al primer bus 13016, junto con un puente de bus 13018 que acopla el primer bus 13016 a un segundo bus 13020. En una realización, un procesador o más procesadores 13015 adicionales, tales como coprocesadores, procesadores de MIC de capacidad de proceso alta, unas GPGPU, aceleradores (tales como, por ejemplo, aceleradores de gráficos o unidades de procesamiento de señales digitales (DSP)), matrices de puertas programables en campo, o cualquier otro procesador, se acoplan al primer bus 13016. En una realización, el segundo bus 13020 puede ser un bus de bajo número de patillas (LPC). Diversos dispositivos pueden acoplarse a un segundo bus 13020 incluyendo, por ejemplo, un teclado y/o ratón 13022, dispositivos de comunicación 13027 y una unidad de almacenamiento 13028, tal como una unidad de disco u otro dispositivo de almacenamiento masivo que puede incluir instrucciones/código y datos 13030, en una realización. Además, una E/S de audio 13024 se puede acoplar al segundo bus 13020. Obsérvese que son posibles otras arquitecturas. Por ejemplo, en lugar de la arquitectura de punto a punto de la Figura 130, un sistema puede implementar un bus multipunto u otra arquitectura de este tipo.
Haciendo referencia ahora a la Figura 131, se muestra un diagrama de bloques de un segundo sistema 13100 ilustrativo más específico de acuerdo con una realización de la presente invención. Elementos semejantes en las Figuras 130 y 131 llevan números de referencia semejantes, y ciertos aspectos de la Figura 130 se han omitido de la figura 131 con el fin de evitar complicar otros aspectos de la Figura 131.
La Figura 131 ilustra que los procesadores 13070, 13080 pueden incluir la memoria integrada y la lógica de control ("CL") de E/S 13072 y 13082, respectivamente. Por lo tanto, las CL 13072, 13082 incluyen unidades de controlador de memoria integrado e incluyen lógica de control de E/S. La Figura 131 ilustra que no solo las memorias 13032, 13034 se acoplan a la CL 13072, 13082, sino también que los dispositivos de E/S 13114 también se acoplan a la lógica de control 13072, 13082. Los dispositivos de E/S heredados 13115 se acoplan al conjunto de chips 13090.
Haciendo referencia ahora a la Figura 132, se muestra un diagrama de bloques de un SoC 13200 de acuerdo con una realización de la presente invención. Elementos semejantes en la Figura 128 llevan números de referencia semejantes. Además, los recuadros con líneas de trazo discontinuo son características opcionales en SoC más avanzados. En la Figura 132, una unidad o unidades de interconexión 13202 están acopladas a: un procesador de aplicación 13210 que incluye un conjunto de uno o más núcleos 12802A-N, que incluyen unidades de caché 12804A-N, y unidad o unidades de caché compartidas 12806; una unidad de agente de sistema 12810; una unidad o unidades de controlador de bus 12816; una unidad o unidades de controlador de memoria integrado 12814; un conjunto o uno o más coprocesadores 13220 que pueden incluir lógica de gráficos integrada, un procesador de imágenes, un procesador de audio y un procesador de vídeo; una unidad de memoria de acceso aleatorio estática (SRAM) 13230; una unidad de acceso a memoria directo (DMA) 13232; y una unidad de visualización 13240 para acoplar a uno o más visualizadores externos. En una realización, el coprocesador o coprocesadores 13220 incluyen un procesador de propósito especial, tal como, por ejemplo, un procesador de red o de comunicación, un motor de compresión, una GPGPU, un procesador de MIC de capacidad de proceso alta, un procesador integrado o similar.
Se pueden implementar realizaciones de los mecanismos divulgados en el presente documento en hardware, software, firmware o una combinación de tales enfoques de implementación. Se pueden implementar realizaciones de la invención como programas informáticos o códigos de programa que se ejecutan en sistemas programables que comprenden al menos un procesador, un sistema de almacenamiento (que incluye memoria volátil y no volátil y/o elementos de almacenamiento), al menos un dispositivo de entrada y al menos un dispositivo de salida.
Un código de programa, tal como el código 13030 ilustrado en la Figura 130, se puede aplicar a unas instrucciones de entrada para realizar las funciones descritas en el presente documento y generar una información de salida. La información de salida se puede aplicar a uno o más dispositivos de salida, de una forma conocida. Para los fines de esta solicitud, un sistema de procesamiento incluye cualquier sistema que tenga un procesador, tal como, por ejemplo; un procesador de señales digitales (DSP), un microcontrolador, un circuito integrado de aplicación específica (ASIC) o un microprocesador.
El código de programa se puede implementar en un lenguaje de programación orientado a objetos o de procedimientos de alto nivel para comunicarse con un sistema de procesamiento. El código de programa también se puede implementar en lenguaje ensamblador o máquina, si se desea. De hecho, los mecanismos descritos en el presente documento no están limitados en su alcance a lenguaje de programación particular alguno. En cualquier caso, el lenguaje puede ser un lenguaje compilado o interpretado.
Uno o más aspectos de al menos una realización se pueden implementar mediante instrucciones representativas almacenadas en un medio legible por máquina que representa diversas lógicas dentro del procesador, que, cuando son leídas por una máquina, hacen que la máquina fabrique una lógica para realizar las técnicas descritas en el presente documento. Tales representaciones, conocidas como "núcleos de IP", se pueden almacenar en un medio legible por máquina tangible y suministrarse a diversos clientes o instalaciones de fabricación para cargarlas en las máquinas de fabricación que realmente hacen la lógica o el procesador.
Tales medios de almacenamiento legibles por máquina pueden incluir, sin limitación, disposiciones tangibles no transitorias de artículos fabricados o formados por una máquina o dispositivo, incluyendo medios de almacenamiento tales como discos duros, cualquier otro tipo de disco, incluyendo disquetes, discos ópticos, discos compactos -memorias de solo lectura (CD-ROM), discos compactos regrabables (CD-RW) y discos magnetoópticos, dispositivos de semiconductores tales como memorias de solo lectura (ROM), memorias de acceso aleatorio (RAM) tales como memorias de acceso aleatorio dinámicas (DRAM), memorias de acceso aleatorio estáticas (SRAM), memorias de solo lectura programables y borrables (EPROM), memorias flash, memorias de solo lectura programables y borrables eléctricamente (EEPROM), memoria de cambio de fase (PCM), tarjetas magnéticas u ópticas, o cualquier otro tipo de medio adecuado para almacenar instrucciones electrónicas.
En consecuencia, realizaciones de la invención también incluyen medios legibles por máquina tangibles no transitorios que contienen instrucciones o que contienen datos de diseño, tales como lenguaje de descripción de hardware (HDL), que definen estructuras, circuitos, aparatos, procesadores y/o características de sistema descritos en el presente documento. Tales realizaciones también se pueden denominar productos de programa.
Emulación (incluyendo traducción binaria, transformación de código, etc.)
En algunos casos, se puede usar un convertidor de instrucciones para convertir una instrucción de un conjunto de instrucciones de origen a un conjunto de instrucciones de destino. Por ejemplo, el convertidor de instrucciones puede traducir (por ejemplo, usando traducción binaria estática, traducción binaria dinámica que incluye compilación dinámica), transformar, emular o convertir de otro modo una instrucción en otras una o más instrucciones a procesar por el núcleo. El convertidor de instrucciones se puede implementar en software, hardware, firmware o una combinación de los mismos. El convertidor de instrucciones puede estar en un procesador, fuera de un procesador o en parte dentro y en parte fuera de un procesador.
La Figura 133 es un diagrama de bloques que contrapone el uso de un convertidor de instrucciones de software para convertir instrucciones binarias en un conjunto de instrucciones de origen en instrucciones binarias en un conjunto de instrucciones de destino de acuerdo con realizaciones de la invención. En la realización ilustrada, el convertidor de instrucciones es un convertidor de instrucciones de software, aunque, como alternativa, el convertidor de instrucciones se puede implementar en software, firmware, hardware o diversas combinaciones de los mismos. La Figura 133 muestra que un programa en un lenguaje de alto nivel 13302 se puede compilar usando un compilador x86 13304 para generar un código binario x86 13306 que puede ser ejecutado de forma nativa por un procesador con al menos un núcleo de conjunto de instrucciones x8613316. El procesador con al menos un núcleo de conjunto de instrucciones x86 13316 representa cualquier procesador que pueda realizar sustancialmente las mismas funciones que un procesador de Intel con al menos un núcleo de conjunto de instrucciones x86 ejecutando o procesando de otro modo, de forma compatible, (1) una porción sustancial del conjunto de instrucciones del núcleo de conjunto de instrucciones x86 de Intel o (2) versiones de código objeto de aplicaciones u otro software destinado a ejecutarse en un procesador de Intel con al menos un núcleo de conjunto de instrucciones x86, con el fin de lograr sustancialmente el mismo resultado que un procesador de Intel con al menos un núcleo de conjunto de instrucciones x86. El compilador x86 13304 representa un compilador que se puede hacer funcionar para generar un código binario x8613306 (por ejemplo, código objeto) que, con o sin un procesamiento de vinculación adicional, se puede ejecutar en el procesador con al menos un núcleo de conjunto de instrucciones x86 13316. De forma similar, la Figura 133 muestra que el programa en el lenguaje de alto nivel 13302 se puede compilar usando un compilador de conjunto de instrucciones alternativo 13308 para generar un código binario de conjunto de instrucciones alternativo 13310 que puede ser ejecutado de forma nativa por un procesador sin al menos un núcleo de conjunto de instrucciones x86 13314 (por ejemplo, un procesador con núcleos que ejecutan el conjunto de instrucciones MIPS de MIPS Technologies de Sunnyvale, CA y/o que ejecutan el conjunto de instrucciones ARM de ARM Holdings de Sunnyvale, CA). El convertidor de instrucciones 13312 se usa para convertir el código binario x86 13306 en un código que puede ser ejecutado de forma nativa por el procesador sin un núcleo de conjunto de instrucciones x86 13314. No es probable que este código convertido sea el mismo que el código binario de conjunto de instrucciones alternativo 13310 debido a que es difícil hacer un convertidor de instrucciones capaz de esto; sin embargo, el código convertido logrará la operación general y estará compuesto por instrucciones a partir del conjunto de instrucciones alternativo. Por lo tanto, el convertidor de instrucciones 13312 representa software, firmware, hardware o una combinación de los mismos que, a través de emulación, simulación o cualquier otro proceso, permite que un procesador u otro dispositivo electrónico que no tiene un procesador o núcleo de conjunto de instrucciones x86 ejecute el código binario x86 13306.
A continuación, se detallan implementaciones y aspectos de ejemplo.
De acuerdo con la invención, un sistema comprende: una pluralidad de elementos de procesamiento heterogéneos; un planificador heterogéneo de hardware para enviar instrucciones para su ejecución en uno o más de la pluralidad de elementos de procesamiento heterogéneos, correspondiendo las instrucciones a un fragmento de código que va ser procesado por uno o más de la pluralidad de elementos de procesamiento heterogéneos, caracterizado por que el planificador heterogéneo traduce el fragmento de código a un formato correspondiente a un tipo de elemento de procesamiento heterogéneo seleccionado usando uno o más convertidores para generar instrucciones que son instrucciones nativas para al menos uno del uno o más de la pluralidad de elementos de procesamiento heterogéneos.
De acuerdo con una realización, la pluralidad de elementos de procesamiento heterogéneos comprende un núcleo de procesador en orden, un núcleo de procesador fuera de orden y un núcleo de procesador de datos empaquetados.
De acuerdo con una realización, la pluralidad de elementos de procesamiento heterogéneos además comprende un acelerador, siendo el acelerador un dispositivo de hardware que realiza funciones de manera más eficiente que los otros elementos de procesamiento heterogéneos.
De acuerdo con una realización, el planificador heterogéneo de hardware comprende, además: un detector de fase de programa para detectar una fase de programa del fragmento de código; en donde la pluralidad de elementos de procesamiento heterogéneos incluye un primer elemento de procesamiento que tiene una primera microarquitectura y un segundo elemento de procesamiento que tiene una segunda microarquitectura diferente de la primera microarquitectura; en donde la fase de programa es una de una pluralidad de fases de programa, incluyendo una primera fase y una segunda fase y el despacho de instrucciones está basado en parte en la fase de programa detectada; en donde el procesamiento del fragmento de código por el primer elemento de procesamiento es para producir características de rendimiento por vatio mejoradas en comparación con el procesamiento del fragmento de código por el segundo elemento de procesamiento.
De acuerdo con una realización, el planificador heterogéneo de hardware comprende, además: un selector para seleccionar un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento para ejecutar el fragmento de código recibido y planificar el fragmento de código en un elemento de procesamiento del tipo de elementos de procesamiento seleccionado mediante el despacho.
De acuerdo con una realización, el fragmento de código es una o más instrucciones asociadas a un hilo de software.
De acuerdo con una realización, para una fase de programa paralelo de datos, el tipo de elemento de procesamiento seleccionado es un núcleo de procesamiento para ejecutar instrucciones de una sola instrucción y múltiples datos (SIMD).
De acuerdo con una realización, para una fase de programa paralelo de datos, el tipo de elemento de procesamiento seleccionado son circuitos que soportan primitivas aritméticas densas.
De acuerdo con una realización, para una fase de programa paralelo de datos el tipo de elemento de procesamiento seleccionado es un acelerador.
De acuerdo con una realización, una fase de programa paralelo de datos comprende elementos de datos que se procesan simultáneamente usando un mismo flujo de control.
De acuerdo con una realización, para una fase de programa paralelo de hilos el tipo de elemento de procesamiento seleccionado es un núcleo de procesamiento escalar.
De acuerdo con una realización, una fase de programa paralelo de hilos comprende ramas dependientes de datos que usan flujos de control únicos.
De acuerdo con una realización, para una fase de programa en serie el tipo de elemento de procesamiento seleccionado es un núcleo fuera de orden.
De acuerdo con una realización, para una fase de programa paralelo de datos, el tipo de elemento de procesamiento seleccionado es un núcleo de procesamiento para ejecutar instrucciones de una sola instrucción y múltiples datos (SIMD).
De acuerdo con un ejemplo, el planificador heterogéneo de hardware debe soportar múltiples tipos de código, que incluyen compilado, intrínseco, ensamblado, bibliotecas, intermedio, de descarga y de dispositivo.
En una realización, el planificador heterogéneo de hardware es para emular la funcionalidad cuando el tipo de elemento de procesamiento seleccionado no puede manejar nativamente el fragmento de código.
En un ejemplo, el planificador heterogéneo de hardware debe emular la funcionalidad cuando un número de hilos de hardware disponibles está sobre-suscrito.
En un ejemplo, el planificador heterogéneo de hardware es para emular la funcionalidad cuando el tipo de elemento de procesamiento seleccionado no puede manejar nativamente el fragmento de código.
En un ejemplo, la selección de un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento heterogéneos es transparente para un usuario.
En un ejemplo, la selección de un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento heterogéneos es transparente para un sistema operativo.
En un ejemplo, el planificador heterogéneo de hardware es presentar un modelo de programación de multiprocesador homogéneo para hacer que cada hilo parezca al programador como si se ejecutara en un núcleo escalar.
En un ejemplo, el modelo de programación de multiprocesadores homogéneos presentado es para presentar una apariencia de soporte para un conjunto de instrucciones completo.
En un ejemplo, la pluralidad de elementos de procesamiento heterogéneos debe compartir un espacio de direcciones de memoria.
En un ejemplo, el planificador de hardware heterogéneo incluye un traductor binario que se ejecutará en uno de los elementos de procesamiento heterogéneos.
En un ejemplo, una selección por defecto de un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento heterogéneos es un núcleo de latencia optimizada.
En un ejemplo, el planificador de hardware heterogéneo para seleccionar un protocolo que va a usarse en una interfaz multiprotocolo para las instrucciones despachadas.
En un ejemplo, un primer protocolo soportado por la interfaz de bus multiprotocolo comprende un protocolo de interfaz de memoria que se usará para acceder a un espacio de direcciones de memoria del sistema.
En un ejemplo, un segundo protocolo soportado por la interfaz de bus multiprotocolo comprende un protocolo de coherencia de caché para mantener la coherencia entre los datos almacenados en una memoria local del acelerador y un subsistema de memoria de un procesador anfitrión que incluye una jerarquía de caché anfitrión y una memoria de sistema.
En un ejemplo, un tercer protocolo soportado por la interfaz de bus multiprotocolo comprende un protocolo de enlace en serie que soporta el descubrimiento de dispositivos, el acceso a registros, la configuración, la inicialización, las interrupciones, el acceso directo a la memoria y los servicios de traducción de direcciones.
En un ejemplo, el tercer protocolo comprende el protocolo de interfaz express de componentes periféricos (PCIe).
En un ejemplo, un sistema incluye: una pluralidad de elementos de procesamiento heterogéneos en un procesador heterogéneo que incluye un acelerador; memoria para almacenar código de programa que es ejecutable por al menos uno de la pluralidad de elementos de procesamiento heterogéneos en un procesador heterogéneo, incluyendo el código de programa: un planificador heterogéneo para enviar instrucciones para su ejecución en uno o más de la pluralidad de elementos de procesamiento heterogéneos, correspondiendo las instrucciones a un fragmento de código que va ser procesado por el uno o más de la pluralidad de elementos de procesamiento heterogéneos, de tal manera que las instrucciones son instrucciones nativas para al menos uno de la pluralidad de elementos de procesamiento heterogéneos.
En un ejemplo, la pluralidad de elementos de procesamiento heterogéneos comprende un núcleo de procesador en orden, un núcleo de procesador fuera de orden y un núcleo de procesador de datos empaquetados.
En un ejemplo, la pluralidad de elementos de procesamiento heterogéneos además comprende un acelerador. En un ejemplo, el planificador heterogéneo incluye además: un detector de fase de programa para detectar una fase de programa del fragmento de código; de tal manera que la pluralidad de elementos de procesamiento heterogéneos incluye un primer elemento de procesamiento que tiene una primera microarquitectura y un segundo elemento de procesamiento que tiene una segunda microarquitectura diferente de la primera microarquitectura; de tal manera que la fase de programa es una de una pluralidad de fases de programa, incluyendo una primera fase y una segunda fase y el despacho de instrucciones está basado en parte en la fase de programa detectada; y de tal manera que el procesamiento del fragmento de código por el primer elemento de procesamiento es para producir características de rendimiento por vatio mejoradas en comparación con el procesamiento del fragmento de código por el segundo elemento de procesamiento.
En un ejemplo, el planificador heterogéneo comprende, además: un selector para seleccionar un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento para ejecutar el fragmento de código recibido y planificar el fragmento de código en un elemento de procesamiento del tipo de elementos de procesamiento seleccionado mediante el despacho.
En un ejemplo, el fragmento de código es una o más instrucciones asociadas a un hilo de software.
En un ejemplo, para una fase de programa paralelo de datos, el tipo de elemento de procesamiento seleccionado es un núcleo de procesamiento para ejecutar instrucciones de una sola instrucción y múltiples datos (SIMD).
En un ejemplo, para una fase de programa paralelo de datos, el tipo de elemento de procesamiento seleccionado son circuitos que soportan primitivas aritméticas densas.
En un ejemplo, para una fase de programa paralelo de datos el tipo de elemento de procesamiento seleccionado es un acelerador.
En un ejemplo, una fase de programa paralelo de datos comprende elementos de datos que se procesan simultáneamente usando un mismo flujo de control.
En un ejemplo, para una fase de programa paralelo de hilos el tipo de elemento de procesamiento seleccionado es un núcleo de procesamiento escalar.
En un ejemplo, una fase de programa paralelo de hilos comprende ramas dependientes de datos que usan flujos de control únicos.
En un ejemplo, para una fase de programa en serie el tipo de elemento de procesamiento seleccionado es un núcleo fuera de orden.
En un ejemplo, para una fase de programa paralelo de datos, el tipo de elemento de procesamiento seleccionado es un núcleo de procesamiento para ejecutar instrucciones de una sola instrucción y múltiples datos (SIMD).
En un ejemplo, el planificador heterogéneo soporta múltiples tipos de código que incluyen el compilado, el intrínseco, el ensamblador, las bibliotecas, el intermedio, de descarga y de dispositivo.
En un ejemplo, el planificador heterogéneo es para emular la funcionalidad cuando el tipo de elemento de procesamiento seleccionado no puede manejar nativamente el fragmento de código.
En un ejemplo, el planificador heterogéneo debe emular la funcionalidad cuando un número de hilos de hardware disponibles está sobre-suscrito.
En un ejemplo, el planificador heterogéneo es para emular la funcionalidad cuando el tipo de elemento de procesamiento seleccionado no puede manejar nativamente el fragmento de código.
En un ejemplo, la selección de un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento heterogéneos es transparente para un usuario.
En un ejemplo, la selección de un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento heterogéneos es transparente para un sistema operativo.
En un ejemplo, el planificador heterogéneo para presentar un modelo de programación homogéneo para hacer que cada hilo parezca al programador como si se ejecutara en un núcleo escalar.
En un ejemplo, el modelo de programación de multiprocesadores homogéneos presentado para presentar una apariencia de soporte para un conjunto de instrucciones completo.
En un ejemplo, la pluralidad de elementos de procesamiento heterogéneos para compartir un espacio de direcciones de memoria.
En un ejemplo, el planificador heterogéneo incluye un traductor binario que se ejecutará en uno de los elementos de procesamiento heterogéneos.
En un ejemplo, una selección por defecto de un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento heterogéneos es un núcleo de latencia optimizada.
En un ejemplo, el planificador de software heterogéneo para seleccionar un protocolo que va a usarse en una interfaz multiprotocolo para las instrucciones despachadas.
En un ejemplo, un primer protocolo soportado por la interfaz de bus multiprotocolo comprende un protocolo de interfaz de memoria que se usará para acceder a un espacio de direcciones de memoria del sistema.
En un ejemplo, un segundo protocolo soportado por la interfaz de bus multiprotocolo comprende un protocolo de coherencia de caché para mantener la coherencia entre los datos almacenados en una memoria local del acelerador y un subsistema de memoria de un procesador anfitrión que incluye una jerarquía de caché anfitrión y una memoria de sistema.
En un ejemplo, un tercer protocolo soportado por la interfaz de bus multiprotocolo comprende un protocolo de enlace en serie que soporta el descubrimiento de dispositivos, el acceso a registros, la configuración, la inicialización, las interrupciones, el acceso directo a la memoria y los servicios de traducción de direcciones.
En un ejemplo, el tercer protocolo comprende el protocolo de interfaz express de componentes periféricos (PCIe).
En un ejemplo un método incluye: recibir una pluralidad de instrucciones; enviar la pluralidad de instrucciones recibidas para su ejecución en uno o más de una pluralidad de elementos de procesamiento heterogéneos, correspondiendo la pluralidad de instrucciones recibidas a un fragmento de código que va ser procesado por el uno o más de la pluralidad de elementos de procesamiento heterogéneos, de manera que la pluralidad de instrucciones son instrucciones nativas para el al menos uno del uno o más de la pluralidad de elementos de procesamiento heterogéneos.
En un ejemplo, la pluralidad de elementos de procesamiento heterogéneos comprende un núcleo de procesador en orden, un núcleo de procesador fuera de orden y un núcleo de procesador de datos empaquetados.
En un ejemplo, la pluralidad de elementos de procesamiento heterogéneos además comprende un acelerador.
En un ejemplo, el método incluye, además: detectar una fase de programa del fragmento de código; de tal manera que la pluralidad de elementos de procesamiento heterogéneos incluye un primer elemento de procesamiento que tiene una primera microarquitectura y un segundo elemento de procesamiento que tiene una segunda microarquitectura diferente de la primera microarquitectura; de tal manera que la fase de programa es una de una pluralidad de fases de programa, incluyendo una primera fase y una segunda fase; y de tal manera que el procesamiento del fragmento de código por el primer elemento de procesamiento es para producir características de rendimiento por vatio mejoradas en comparación con el procesamiento del fragmento de código por el segundo elemento de procesamiento.
En un ejemplo, el método incluye, además: seleccionar un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento para ejecutar el fragmento de código recibido y planificar el fragmento de código en un elemento de procesamiento del tipo de elementos de procesamiento seleccionado.
En un ejemplo, un fragmento de código es una o más instrucciones asociadas a un hilo de software.
En un ejemplo, para una fase de programa paralelo de datos, el tipo de elemento de procesamiento seleccionado es un núcleo de procesamiento para ejecutar instrucciones de una sola instrucción y múltiples datos (SIMD).
En un ejemplo, para una fase de programa paralelo de datos, el tipo de elemento de procesamiento seleccionado son circuitos que soportan primitivas aritméticas densas.
En un ejemplo, para una fase de programa paralelo de datos el tipo de elemento de procesamiento seleccionado es un acelerador.
En un ejemplo, una fase de programa paralelo de datos está caracterizada por elementos de datos que se procesan simultáneamente usando un mismo flujo de control.
En un ejemplo, para una fase de programa paralelo de hilos el tipo de elemento de procesamiento seleccionado es un núcleo de procesamiento escalar.
En un ejemplo, una fase de programa paralelo de hilos está caracterizada por ramas dependientes de datos que usan flujos de control únicos.
En un ejemplo, para una fase de programa en serie el tipo de elemento de procesamiento seleccionado es un núcleo fuera de orden.
En un ejemplo, para una fase de programa paralelo de datos, el tipo de elemento de procesamiento seleccionado es un núcleo de procesamiento para ejecutar instrucciones de una sola instrucción y múltiples datos (SIMD).
En un ejemplo, el método incluye, además: emular la funcionalidad cuando el tipo de elemento de procesamiento seleccionado no puede manejar nativamente el fragmento de código.
En un ejemplo, el método incluye, además: emular la funcionalidad cuando un número de hilos de hardware disponibles está sobre-suscrito.
En un ejemplo, la selección de un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento heterogéneos es transparente para un usuario.
En un ejemplo, la selección de un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento heterogéneos es transparente para un sistema operativo.
En un ejemplo, el método incluye, además: presentar un modelo de programación multiprocesador homogéneo para que cada hilo aparezca como si se ejecutara en un núcleo escalar.
En un ejemplo, el modelo de programación de multiprocesadores homogéneos presentado es para presentar una apariencia de soporte para un conjunto de instrucciones completo.
En un ejemplo, la pluralidad de elementos de procesamiento heterogéneos para compartir un espacio de direcciones de memoria.
En un ejemplo, el método incluye, además: la traducción binaria del fragmento de código que se ejecutará en uno de los elementos de procesamiento heterogéneos.
En un ejemplo, una selección por defecto de un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento heterogéneos es un núcleo de latencia optimizada.
En un ejemplo, un medio legible por máquina no transitorio almacena instrucciones que cuando son ejecutadas por un procesador de hardware realizan el método.
En un ejemplo un método incluye: recibir un fragmento de código en un planificador heterogéneo; determinar si el fragmento de código está en una fase paralela; cuando el fragmento de código no está en una fase paralela, seleccionar un elemento de procesamiento sensible a la latencia para ejecutar el fragmento de código; cuando el fragmento de código está en una fase paralela, determinar un tipo de paralelismo, y para un fragmento de código paralelo de hilo, seleccionar un elemento de procesamiento escalar para ejecutar el fragmento de código, y para un fragmento de código paralelo a los datos, determinar una disposición de datos del fragmento de código paralelo a los datos: para una disposición de datos empaquetados, seleccionar uno de los elementos de procesamiento de una sola instrucción, múltiples datos (SIMD) y un elemento de procesamiento de primitiva aritmética, y para una disposición de datos aleatoria, seleccionar uno de los elementos de procesamiento SIMD que usa instrucciones de recopilación, una matriz de cálculo espacial, o un núcleo escalar de una matriz de núcleos escalares; y transmitir el fragmento de código a un elemento de procesamiento para su ejecución.
En un ejemplo el método incluye, además: determinar cuándo el fragmento de código está sujeto a una descarga a un acelerador antes de determinar si el fragmento de código está en una fase paralela; transmitir el fragmento de código al acelerador cuando el fragmento de código está sujeto a una descarga.
En un ejemplo, la determinación de si el fragmento de código está en una fase paralela se basa en una o más de las dependencias de datos detectadas, los tipos de instrucciones y las instrucciones de flujo de control.
En un ejemplo, las instrucciones del tipo de instrucción única, múltiples datos, indican una fase paralela.
En un ejemplo, a cada hilo del sistema operativo manejado por el planificador heterogéneo se le asigna un identificador lógico de hilo.
En un ejemplo, el planificador heterogéneo utiliza un mapeo en franjas de los identificadores de hilos lógicos, de manera que cada identificador de hilo lógico se mapea a una tupla de un tipo de elemento de procesamiento, un identificador de elemento de procesamiento y un identificador de hilo.
En un ejemplo, un mapeo desde el identificador de hilo lógico hasta el identificador de elemento de procesamiento y el identificador de hilo se calcula a través de la división y el módulo.
En un ejemplo, se fija un mapeo del identificador de hilo lógico al identificador de elemento de procesamiento y al identificador de hilo para preservar la afinidad de los hilos.
En un ejemplo, el planificador heterogéneo realiza un mapeo del identificador de hilo lógico al tipo de elemento de procesamiento.
En un ejemplo, un mapeo del identificador de hilo lógico al tipo de elemento de procesamiento es flexible para acomodar futuros tipos de elementos de procesamiento.
En un ejemplo, el planificador heterogéneo debe utilizar grupos de núcleos de manera que al menos uno de los grupos de núcleos comprenda al menos una tupla fuera de orden y tuplas escalares y SIMD cuyos identificadores lógicos de hilos se mapean a la misma tupla fuera de orden.
En un ejemplo, una fase no paralela está determinada por un hilo que tiene un valor de registro base de directorio de páginas único entre los hilos que pertenecen a uno de los grupos del núcleo.
En un ejemplo, los hilos que pertenecen a un proceso comparten un mismo espacio de direcciones, tabla de páginas y valor del registro base del directorio de páginas.
En un ejemplo, el método incluye, además: detectar un evento, de manera que el evento es uno de los comandos de reactivación de hilos; una escritura en un registro base del directorio de páginas; un comando de inactividad; un cambio de fase en el hilo; y una o más instrucciones que indican una reasignación deseada a un núcleo diferente.
En un ejemplo, el método incluye además: cuando el evento es un comando de reactivación de hilo: determinar que el fragmento de código está en una fase paralela, contando un número de elementos de procesamiento que comparten un mismo puntero de base de tabla de páginas que el hilo que se reactivó; determinar si el número de elementos de procesamiento contados es mayor que uno; cuando el recuento del número de elementos de procesamiento que comparten un mismo puntero de base de tabla de páginas que el hilo que se reactivó es uno, el hilo está en una fase serie; y cuando el recuento del número de elementos de procesamiento que comparten un mismo puntero de base de tabla de páginas que el hilo que se reactivó no es uno, el hilo está en una fase paralela.
En un ejemplo, el método incluye, además: cuando el evento es una orden de inactividad de un hilo: borrar una bandera de ejecución asociada al hilo, contar un número de hilos de elementos de procesamiento que comparten el mismo puntero base de tabla de páginas que el hilo afectado, determinar si un elemento de procesamiento fuera de orden está inactivo; cuando el puntero base de la tabla de páginas es compartido por exactamente un hilo en el grupo de núcleos, entonces ese hilo que comparte es movido de un elemento de procesamiento fuera de orden, cuando el puntero base de la tabla de páginas es compartido por más de un hilo, entonces el primer hilo en ejecución del grupo de núcleos se migra al elemento de procesamiento fuera de orden.
En un ejemplo, el comando de inactividad del hilo es uno de los comandos de detención, entrada de espera y tiempo de espera, o pausa.
En un ejemplo, el método incluye, además: cuando el evento es un cambio de fase: cuando un identificador de hilo lógico de un hilo indica que se está ejecutando en un elemento de procesamiento escalar y hay instrucciones SIMD, migrar el hilo a un elemento de procesamiento SIMD; cuando el identificador lógico de un hilo indica que se está ejecutando en un elemento de procesamiento SIMD y no hay instrucciones SIMD, migrar el hilo a un elemento de procesamiento escalar.
En un ejemplo el método incluye, además: traducir el fragmento de código para que se ajuste mejor al elemento de procesamiento seleccionado antes de transmitir el fragmento de código.
En un ejemplo, el planificador heterogéneo incluye un traductor binario para realizar la traducción.
En un ejemplo, el planificador heterogéneo incluye un compilador justo a tiempo para realizar la traducción.
En un ejemplo, un sistema incluye: una pluralidad de elementos de procesamiento heterogéneos; un planificador heterogéneo para determinar una fase de un fragmento de código y transmitir el fragmento de código a uno de la pluralidad de elementos de procesamiento heterogéneos para su ejecución basándose, al menos en parte, en la fase determinada.
En un ejemplo, el planificador heterogéneo debe: determinar el fragmento de código está en una fase paralela; cuando el fragmento de código no está en una fase paralela, seleccionar un elemento de procesamiento sensible a la latencia para ejecutar el fragmento de código; cuando el fragmento de código está en una fase paralela, determinar un tipo de paralelismo, y para un fragmento de código paralelo de hilo, seleccionar un elemento de procesamiento escalar para ejecutar el fragmento de código, y para un fragmento de código paralelo a los datos, determinar una disposición de datos del fragmento de código paralelo a los datos: para una disposición de datos empaquetados, seleccionar uno de los elementos de procesamiento de una sola instrucción, múltiples datos (SIMD) y un elemento de procesamiento de primitiva aritmética, y para una disposición de datos aleatoria, seleccionar uno de los elementos de procesamiento SIMD que usa instrucciones de recopilación, una matriz de cálculo espacial, o un núcleo escalar de una matriz de núcleos escalares.
En un ejemplo, el planificador heterogéneo debe, además: determinar cuándo el fragmento de código está sujeto a una descarga a un acelerador antes de determinar si el fragmento de código está en una fase paralela; transmitir el fragmento de código al acelerador cuando el fragmento de código está sujeto a una descarga.
En un ejemplo, el planificador heterogéneo debe, además: determinar si el fragmento de código está en una fase paralela se basa en una o más de las dependencias de datos detectadas, los tipos de instrucciones y las instrucciones de flujo de control.
En un ejemplo, las instrucciones del tipo de instrucción única, múltiples datos, indican una fase paralela.
En un ejemplo, a cada hilo del sistema operativo manejado por el planificador heterogéneo se le asigna un identificador lógico de hilo.
En un ejemplo, el planificador heterogéneo debe utilizar un mapeo en franjas de los identificadores de hilos lógicos, de manera que cada identificador de hilo lógico se mapea a una tupla de un tipo de elemento de procesamiento, un identificador de elemento de procesamiento y un identificador de hilo.
En un ejemplo, un mapeo desde el identificador de hilo lógico hasta el identificador de elemento de procesamiento y el identificador de hilo se calcula a través de la división y el módulo.
En un ejemplo, se fija un mapeo del identificador de hilo lógico al identificador de elemento de procesamiento y al identificador de hilo para preservar la afinidad de los hilos.
En un ejemplo, el planificador heterogéneo realiza un mapeo del identificador de hilo lógico al tipo de elemento de procesamiento.
En un ejemplo un mapeo del identificador de hilo lógico al tipo de elemento de procesamiento es flexible para acomodar futuros tipos de elementos de procesamiento.
En un ejemplo, el planificador heterogéneo debe utilizar grupos de núcleos de manera que un grupo de núcleos comprenda al menos una tupla fuera de orden y tuplas escalares y SIMD cuyos identificadores lógicos de hilos se mapean a la misma tupla fuera de orden.
En un ejemplo, una fase no paralela está determinada por un hilo que tiene un valor de registro base de directorio de páginas único entre los hilos que pertenecen a uno de los grupos del núcleo.
En un ejemplo, los hilos que pertenecen a un proceso comparten un mismo espacio de direcciones, tabla de páginas y valor del registro base del directorio de páginas.
En un ejemplo, el planificador heterogéneo debe: detectar un evento, de manera que el evento es uno de los comandos de reactivación de hilos; una escritura en un registro base del directorio de páginas; un comando de inactividad; un cambio de fase en el hilo; y una o más instrucciones que indican una reasignación deseada.
En un ejemplo, el planificador heterogéneo debe: cuando el evento es un comando de reactivación de un hilo: determinar que el fragmento de código está en una fase paralela, contar un número de elementos de procesamiento que comparten un mismo puntero de base de tabla de páginas que el hilo que se reactivó; determinar si el número de elementos de procesamiento contados es mayor que uno; cuando el recuento del número de elementos de procesamiento que comparten un mismo puntero de base de tabla de páginas que el hilo que se reactivó es uno, el hilo está en una fase serie; y cuando el recuento del número de elementos de procesamiento que comparten un mismo puntero de base de tabla de páginas que el hilo que se reactivó no es uno, el hilo está en una fase paralela.
En un ejemplo, el planificador heterogéneo debe: cuando el evento es una orden de pasar a inactividad un hilo: borrar una bandera de ejecución asociada al hilo; contar un número de hilos de elementos de procesamiento que comparten el mismo puntero base de tabla de páginas que el hilo afectado; determinar si un elemento de procesamiento fuera de orden está inactivo; cuando el puntero base de la tabla de páginas es compartido por exactamente un hilo en el grupo de núcleos, entonces ese hilo que comparte es movido de un elemento de procesamiento fuera de orden, cuando el puntero base de la tabla de páginas es compartido por más de un hilo, entonces el primer hilo en ejecución del grupo se migra al elemento de procesamiento fuera de orden.
En un ejemplo, el comando de inactividad del hilo es uno de los comandos de detención, entrada de espera y tiempo de espera, o pausa.
En un ejemplo, el planificador heterogéneo debe: cuando el evento es un cambio de fase: cuando un identificador de hilo lógico de un hilo indica que se está ejecutando en un elemento de procesamiento escalar y hay instrucciones SIMD, migrar el hilo a un elemento de procesamiento SIMD; cuando el identificador lógico de un hilo indica que se está ejecutando en un elemento de procesamiento SIMD y no hay instrucciones SIMD, migrar el hilo a un elemento de procesamiento escalar.
En un ejemplo, el planificador heterogéneo para: traducir el fragmento de código para que se ajuste mejor al elemento de procesamiento seleccionado antes de transmitir el fragmento de código.
En un ejemplo, el planificador heterogéneo incluye un traductor binario almacenado en un medio legible por máquina no transitorio para realizar la traducción tras la ejecución.
En un ejemplo, el planificador heterogéneo incluye un compilador justo a tiempo almacenado en un medio legible por máquina no transitorio para realizar la traducción tras la ejecución.
En un ejemplo, un sistema incluye, además: memoria para almacenar código de programa que es ejecutable por al menos uno de la pluralidad de los elementos de procesamiento heterogéneos en un procesador heterogéneo para proporcionar el planificador heterogéneo.
En un ejemplo, el planificador heterogéneo comprende circuitos.
En un ejemplo, un procesador incluye: un núcleo de procesador, el núcleo de procesador incluye: un decodificador para decodificar al menos una instrucción nativa del núcleo de procesador; una o más unidades de ejecución para ejecutar al menos una instrucción decodificada, correspondiendo la al menos una instrucción decodificada a una instrucción de inicio de aceleración, siendo la instrucción de inicio de aceleración para indicar el comienzo de una región de código que debe descargarse a un acelerador.
En un ejemplo, la región de código debe descargarse basándose en si un acelerador de destino está acoplado al núcleo del procesador y disponible para procesar la región de código, de manera que, cuando el acelerador de destino no está acoplado al núcleo del procesador para procesar la región de código, la región de código debe ser procesada por el núcleo del procesador.
En un ejemplo, en respuesta a la ejecución de la al menos una instrucción decodificada correspondiente a la instrucción de inicio de la aceleración, el núcleo del procesador pasa de un primer modo de ejecución a un segundo modo de ejecución.
En un ejemplo, en el primer modo de ejecución, el núcleo del procesador debe comprobar si hay código que se modifica a sí mismo, y en el segundo modo de ejecución, el núcleo del procesador debe desactivar la comprobación del código que se modifica a sí mismo.
En un ejemplo, para desactivar una comprobación de código que se modifica a sí mismo, se desactiva el circuito de detección de código que se modifica a sí mismo.
En un ejemplo, en el primer modo de ejecución, las restricciones del modelo de consistencia de memoria se debilitan al relajar los requisitos de ordenación de la memoria.
En un ejemplo, en el primer modo de ejecución, la semántica de coma flotante se altera mediante la configuración de un registro de palabra de control de coma flotante.
En un ejemplo, un método incluye: decodificar una instrucción nativa del núcleo del procesador; ejecutar la instrucción decodificada correspondiente a una instrucción de inicio de aceleración, la instrucción de inicio de aceleración para indicar el comienzo de una región de código que debe descargarse a un acelerador.
En un ejemplo, la región de código debe descargarse basándose en si un acelerador de destino está acoplado al núcleo del procesador y disponible para procesar la región de código, de manera que, cuando el acelerador de destino no está acoplado al núcleo del procesador para procesar la región de código, la región de código debe ser procesada por el núcleo del procesador.
En un ejemplo, en respuesta a la ejecución de la instrucción decodificada correspondiente a la instrucción de inicio de la aceleración, el núcleo del procesador pasa de un primer modo de ejecución a un segundo modo de ejecución. En un ejemplo, en el primer modo de ejecución, el núcleo del procesador debe comprobar si hay código que se modifica a sí mismo, y en el segundo modo de ejecución, el núcleo del procesador debe desactivar la comprobación del código que se modifica a sí mismo.
En un ejemplo, para desactivar una comprobación de código que se modifica a sí mismo, se desactiva el circuito de detección de código que se modifica a sí mismo.
En un ejemplo, en el primer modo de ejecución, las restricciones del modelo de consistencia de memoria se debilitan al relajar los requisitos de ordenación de la memoria.
En un ejemplo, en el primer modo de ejecución, la semántica de coma flotante se altera mediante la configuración de un registro de palabra de control de coma flotante.
En un ejemplo, un medio no transitorio legible por máquina almacena una instrucción que, al ser ejecutada por un procesador, hace que éste realice un método, incluyendo el método: decodificar una instrucción nativa del núcleo del procesador; ejecutar la instrucción decodificada correspondiente a una instrucción de inicio de aceleración, la instrucción de inicio de aceleración para indicar el comienzo de una región de código que debe descargarse a un acelerador.
En un ejemplo, la región de código debe descargarse basándose en si un acelerador de destino está acoplado al núcleo del procesador y disponible para procesar la región de código, de manera que, cuando el acelerador de destino no está acoplado al núcleo del procesador para procesar la región de código, la región de código debe ser procesada por el núcleo del procesador.
En un ejemplo, en respuesta a la ejecución de la instrucción decodificada correspondiente a la instrucción de inicio de la aceleración, el núcleo del procesador pasa de un primer modo de ejecución a un segundo modo de ejecución. En un ejemplo, en el primer modo de ejecución, el núcleo del procesador debe comprobar si hay código que se modifica a sí mismo, y en el segundo modo de ejecución, el núcleo del procesador debe desactivar la comprobación del código que se modifica a sí mismo.
En un ejemplo, para desactivar una comprobación de código que se modifica a sí mismo, se desactiva el circuito de detección de código que se modifica a sí mismo.
En un ejemplo, en el primer modo de ejecución, las restricciones del modelo de consistencia de memoria se debilitan al relajar los requisitos de ordenación de la memoria.
En un ejemplo, en el primer modo de ejecución, la semántica de coma flotante se altera mediante la configuración de un registro de palabra de control de coma flotante.
En un ejemplo, un sistema incluye: un núcleo de procesador, el núcleo de procesador incluye: un decodificador para decodificar al menos una instrucción nativa del núcleo de procesador; una o más unidades de ejecución para ejecutar al menos una instrucción decodificada, correspondiendo la al menos una instrucción decodificada a una instrucción de inicio de aceleración, siendo la instrucción de inicio de aceleración para indicar el comienzo de una región de código que debe descargarse a un acelerador.
En un ejemplo, la región de código debe descargarse basándose en si un acelerador de destino está acoplado al núcleo del procesador y disponible para procesar la región de código, de manera que, cuando el acelerador de destino no está acoplado al núcleo del procesador para procesar la región de código, la región de código debe ser procesada por el núcleo del procesador.
En un ejemplo, en respuesta a la ejecución de la al menos una instrucción decodificada correspondiente a la instrucción de inicio de la aceleración, el núcleo del procesador pasa de un primer modo de ejecución a un segundo modo de ejecución.
En un ejemplo, en el primer modo de ejecución, el núcleo del procesador debe comprobar si hay código que se modifica a sí mismo, y en el segundo modo de ejecución, el núcleo del procesador debe desactivar la comprobación del código que se modifica a sí mismo.
En un ejemplo, para desactivar una comprobación de código que se modifica a sí mismo, se desactiva el circuito de detección de código que se modifica a sí mismo.
En un ejemplo, en el primer modo de ejecución, las restricciones del modelo de consistencia de memoria se debilitan al relajar los requisitos de ordenación de la memoria.
En un ejemplo, en el primer modo de ejecución, la semántica de coma flotante se altera mediante la configuración de un registro de palabra de control de coma flotante.
En un ejemplo, un procesador incluye: un núcleo de procesador, el núcleo de procesador incluye: un decodificador para decodificar una instrucción nativa del núcleo de procesador; una o más unidades de ejecución para ejecutar la instrucción decodificada correspondiente a una instrucción de fin de aceleración, la instrucción de fin de aceleración para indicar el fin de una región de código que debe descargarse a un acelerador.
En un ejemplo, la región de código debe descargarse basándose en si un acelerador de destino está acoplado al núcleo del procesador y disponible para procesar la región de código, de manera que, cuando el acelerador de destino no está acoplado al núcleo del procesador para recibir y procesar la región de código, la región de código debe ser procesada por el núcleo del procesador.
En un ejemplo, la región de código está delineada por una ejecución de una instrucción decodificada correspondiente a una instrucción de inicio de aceleración que es la transición del núcleo del procesador de un primer modo de ejecución a un segundo modo de ejecución.
En un ejemplo, en el primer modo de ejecución, el procesador debe comprobar si hay código que se modifica a sí mismo, y en el segundo modo de ejecución, el procesador debe desactivar la comprobación del código que se modifica a sí mismo.
En un ejemplo, para desactivar una comprobación de código que se modifica a sí mismo, se desactiva el circuito de detección de código que se modifica a sí mismo.
En un ejemplo, en el primer modo de ejecución, las restricciones del modelo de consistencia de memoria se debilitan. En un ejemplo, en el primer modo de ejecución, la semántica de coma flotante se altera mediante la configuración de un registro de palabra de control de coma flotante.
En un ejemplo, la ejecución de la instrucción de inicio del acelerador bloquea la ejecución de la región de código en el núcleo del procesador hasta que se ejecuta la instrucción de fin del acelerador.
En un ejemplo, un método incluye: decodificar una instrucción nativa del núcleo del procesador; ejecutar la instrucción decodificada correspondiente a una instrucción de fin de aceleración, la instrucción de fin de aceleración para indicar el fin de una región de código que debe descargarse a un acelerador.
En un ejemplo, la región de código debe descargarse basándose en si un acelerador de destino está acoplado al núcleo del procesador y disponible para procesar la región de código, de manera que, cuando el acelerador de destino no está acoplado al núcleo del procesador para recibir y procesar la región de código, la región de código debe ser procesada por el núcleo del procesador.
En un ejemplo, la región de código está delineada por una ejecución de una instrucción decodificada correspondiente a una instrucción de inicio de aceleración que es la transición del núcleo del procesador de un primer modo de ejecución a un segundo modo de ejecución.
En un ejemplo, en el primer modo de ejecución, el procesador debe comprobar si hay código que se modifica a sí mismo, y en el segundo modo de ejecución, el procesador debe desactivar la comprobación del código que se modifica a sí mismo.
En un ejemplo, para desactivar una comprobación de código que se modifica a sí mismo, se desactiva el circuito de detección de código que se modifica a sí mismo.
En un ejemplo, en el primer modo de ejecución, las restricciones del modelo de consistencia de memoria se debilitan.
En un ejemplo, en el primer modo de ejecución, la semántica de coma flotante se altera mediante la configuración de un registro de palabra de control de coma flotante.
En un ejemplo, la ejecución de la instrucción de inicio del acelerador bloquea la ejecución de la región de código en el núcleo del procesador hasta que se ejecuta la instrucción de fin del acelerador.
En un ejemplo, un medio no transitorio legible por máquina almacena una instrucción que, al ser ejecutada por un procesador, hace que éste realice un método, incluyendo el método: decodificar una instrucción nativa del núcleo del procesador; ejecutar la instrucción decodificada correspondiente a una instrucción de fin de aceleración, la instrucción de fin de aceleración para indicar el fin de una región de código que debe descargarse a un acelerador.
En un ejemplo, la región de código debe descargarse basándose en si un acelerador de destino está acoplado al núcleo del procesador y disponible para procesar la región de código, de manera que, cuando el acelerador de destino no está acoplado al núcleo del procesador para recibir y procesar la región de código, la región de código debe ser procesada por el núcleo del procesador.
En un ejemplo, la región de código está delineada por una ejecución de una instrucción decodificada correspondiente a una instrucción de inicio de aceleración que es la transición del núcleo del procesador de un primer modo de ejecución a un segundo modo de ejecución.
En un ejemplo, en el primer modo de ejecución, el procesador debe comprobar si hay código que se modifica a sí mismo, y en el segundo modo de ejecución, el procesador debe desactivar la comprobación del código que se modifica a sí mismo.
En un ejemplo, para desactivar una comprobación de código que se modifica a sí mismo, se desactiva el circuito de detección de código que se modifica a sí mismo.
En un ejemplo, en el primer modo de ejecución, las restricciones del modelo de consistencia de memoria se debilitan.
En un ejemplo, en el primer modo de ejecución, la semántica de coma flotante se altera mediante la configuración de un registro de palabra de control de coma flotante.
En un ejemplo, la ejecución de la instrucción de inicio del acelerador bloquea la ejecución de la región de código en el núcleo del procesador hasta que se ejecuta la instrucción de fin del acelerador.
En un ejemplo, un sistema incluye: un núcleo de procesador, el núcleo de procesador incluye: un decodificador para decodificar una instrucción nativa del núcleo de procesador; una o más unidades de ejecución para ejecutar la instrucción decodificada correspondiente a una instrucción de fin de aceleración, la instrucción de fin de aceleración para indicar el fin de una región de código que debe descargarse a un acelerador; un acelerador para ejecutar las instrucciones descargadas.
En un ejemplo, la región de código debe descargarse basándose en si un acelerador de destino está acoplado al núcleo del procesador y disponible para procesar la región de código, de manera que, cuando el acelerador de destino no está acoplado al núcleo del procesador para recibir y procesar la región de código, la región de código debe ser procesada por el núcleo del procesador.
En un ejemplo, la región de código está delineada por una ejecución de una instrucción decodificada correspondiente a una instrucción de inicio de aceleración que es la transición del núcleo del procesador de un primer modo de ejecución a un segundo modo de ejecución.
En un ejemplo, en el primer modo de ejecución, el procesador debe comprobar si hay código que se modifica a sí mismo, y en el segundo modo de ejecución, el procesador debe desactivar la comprobación del código que se modifica a sí mismo.
En un ejemplo, para desactivar una comprobación de código que se modifica a sí mismo, se desactiva el circuito de detección de código que se modifica a sí mismo.
En un ejemplo, en el primer modo de ejecución, las restricciones del modelo de consistencia de memoria se debilitan.
En un ejemplo, en el primer modo de ejecución, la semántica de coma flotante se altera mediante la configuración de un registro de palabra de control de coma flotante.
En un ejemplo, la ejecución de la instrucción de inicio del acelerador bloquea la ejecución de la región de código en el núcleo del procesador hasta que se ejecuta la instrucción de fin del acelerador.
En un ejemplo, un sistema incluye: un acelerador para ejecutar un hilo;
un núcleo de procesador; y una memoria que tiene almacenado en la misma, un software para implementar un planificador heterogéneo, de tal manera que, cuando es ejecutado por el núcleo del procesador, el planificador heterogéneo es para: detectar una secuencia de código en un hilo adecuado para la ejecución potencial en el acelerador, seleccionar el acelerador para ejecutar la secuencia de código detectada, transmitir la secuencia de código detectada al acelerador seleccionado.
En un ejemplo, el sistema incluye, además: una pluralidad de elementos de procesamiento heterogéneos para ejecutar fases de programa del hilo no adecuadas para ser ejecutadas por el acelerador.
En un ejemplo, el planificador heterogéneo comprende, además: un comparador de patrones para reconocer la secuencia de códigos comparando la secuencia de códigos con un conjunto predeterminado de patrones.
En un ejemplo, el conjunto predeterminado de patrones se almacena en la memoria.
En un ejemplo, el planificador heterogéneo para usar la monitorización del rendimiento para reconocer el código que tiene una coincidencia de patrón y ajustar un modo de operación asociado con el hilo mediante la configuración del núcleo del procesador para hacer uno o más de lo siguiente: ignorar el código que se modifica a sí mismo, debilitar las restricciones del modelo de consistencia de la memoria, alterar la semántica de coma flotante, cambiar la monitorización del rendimiento, y alterar el uso de la bandera arquitectónica.
En un ejemplo, el planificador heterogéneo además comprende un módulo de traducción para traducir el código reconocido en código del acelerador para que el acelerador lo ejecute.
En un ejemplo, el núcleo del procesador comprende: circuitos de coincidencia de patrones para detectar una secuencia de códigos en el hilo usando patrones almacenados.
En un ejemplo, el núcleo del procesador debe mantener un estado de ejecución de cada hilo que se ejecuta en el sistema.
En un ejemplo, el planificador heterogéneo debe mantener un estado de cada hilo que se ejecuta en el sistema. En un ejemplo, el planificador heterogéneo debe seleccionar el acelerador basándose en una o más de las informaciones de los elementos del procesador, los hilos rastreados y las secuencias de código detectadas.
En un ejemplo, un sistema incluye: una pluralidad de elementos de procesamiento heterogéneos; un circuito planificador heterogéneo acoplado a la pluralidad de elementos de procesamiento, incluyendo el circuito planificador heterogéneo: una tabla de seguimiento de hilos y elementos de procesamiento para mantener un estado de ejecución de cada hilo en ejecución y de cada elemento de procesamiento; un selector para seleccionar un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento heterogéneos para procesar un fragmento de código y planificar el fragmento de código en uno de la pluralidad de elementos de procesamiento heterogéneos para su ejecución, basándose en el estado del rastreador de hilos y elementos de procesamiento y en la información del elemento de procesamiento.
En un ejemplo, el sistema incluye, además: memoria para almacenar software ejecutable por un núcleo de procesador, el software para detectar una secuencia de código en un hilo para su potencial ejecución en un acelerador que es uno de la pluralidad de elementos de procesamiento heterogéneos acoplados al circuito planificador heterogéneo.
En un ejemplo, el comparador de patrones de software para reconocer la secuencia de códigos de un patrón almacenado.
En un ejemplo, el planificador heterogéneo debe traducir el código reconocido en código del acelerador.
En un ejemplo, el selector es una máquina de estados finitos ejecutada por el circuito planificador heterogéneo. En un ejemplo un método incluye: ejecutar un hilo; detectar un patrón en el hilo de ejecución; traducir el patrón reconocido al código del acelerador; y transferir el patrón traducido a un acelerador disponible para su ejecución. En un ejemplo, el patrón se reconoce usando un comparador de patrones de software.
En un ejemplo, el patrón se reconoce usando un circuito de comparación de patrones de hardware.
En un ejemplo un método incluye: ejecutar un hilo; detectar un patrón en el hilo de ejecución; ajustar un modo de operación asociado al hilo para utilizar requisitos relajados basándose en el patrón.
En un ejemplo, el patrón se reconoce usando un comparador de patrones de software.
En un ejemplo, el patrón se reconoce usando un circuito de comparación de patrones de hardware.
En un ejemplo, en el modo de operación ajustado se aplica uno o más de lo siguiente: se ignora el código que se modifica a sí mismo, se debilitan las restricciones del modelo de consistencia de la memoria, se altera la semántica de la coma flotante, se modifica la monitorización del rendimiento y se altera el uso de las banderas arquitectónicas.
En un ejemplo, un sistema incluye: un decodificador para decodificar una instrucción nativa del núcleo del procesador; una o más unidades de ejecución para ejecutar la instrucción decodificada, correspondiendo una o más de las instrucciones decodificadas a una instrucción de inicio de aceleración, la instrucción de inicio de aceleración para provocar la entrada en un modo de ejecución diferente para las instrucciones que siguen a la instrucción de inicio de aceleración en un mismo hilo.
En un ejemplo, la instrucción de inicio de aceleración incluye un campo para especificar un puntero a un bloque de datos de memoria, de manera que un formato del bloque de datos de memoria incluye un campo de número de secuencia para indicar el progreso antes de una interrupción.
En un ejemplo, la instrucción de inicio de aceleración incluye un campo identificador de clase de bloque para especificar traducciones predefinidas de código almacenado en la memoria.
En un ejemplo, la instrucción de inicio de aceleración incluye un campo identificador de implementación para indicar un tipo de hardware a usar para la ejecución.
En un ejemplo, la instrucción de inicio de aceleración incluye un campo de tamaño de área de grabación de estado para indicar un tamaño y formato de un área de grabación de estado que va a almacenar registros que se modificarán después de que se ejecute la instrucción de inicio de aceleración.
En un ejemplo, la instrucción de inicio de aceleración incluye un campo para el tamaño del área de almacenamiento local, de manera que el área de almacenamiento local debe proporcionar almacenamiento más allá de los registros.
En un ejemplo, el tamaño del área de almacenamiento local está definido por un operando inmediato de la instrucción de inicio de aceleración.
En un ejemplo, no se debe acceder al área de almacenamiento local fuera de las instrucciones que siguen a la instrucción de inicio de aceleración.
En un ejemplo, para las instrucciones dentro del modo de ejecución diferente se puede definir un tipo de dependencia de memoria.
En un ejemplo, el tipo de dependencia de memoria definible comprende uno de los siguientes: un tipo independiente, en el que se garantiza que no existen dependencias de almacén -carga y almacén - almacén; un acceso potencialmente dependiente al tipo de área de almacenamiento local, en el que las cargas y los almacenes del área de almacenamiento local pueden depender unos de otros, pero son independientes de otras cargas y almacenes; un tipo potencialmente dependiente, en el que el hardware comprobará y aplicará dinámicamente las dependencias entre instrucciones; y un tipo atómico, en el que las cargas y los almacenes son dependientes entre sí y la memoria se actualiza atómicamente.
En un ejemplo, el sistema incluye, además: memoria para almacenar: estado de grabación, que incluye los registros que se van a usar, las banderas que se van a actualizar y la información de especificación de la implementación; y el almacenamiento local que se usará durante la ejecución más allá de los registros.
En un ejemplo, cada instancia de ejecución paralela obtiene su propio almacenamiento local.
En un ejemplo un método incluye: introducir un modo de ejecución diferente y relajado para un hilo; escribir, en un área de estado grabación, los registros que se usarán durante la ejecución del hilo durante el modo de ejecución diferente y relajado; reservar el almacenamiento local para ser usado por la ejecución paralela en el hilo durante el modo de ejecución diferente y relajado; ejecutar un bloque de las instrucciones de hilo y rastreo dentro del modo de ejecución diferente y relajado; determinar si se ha alcanzado el final del modo de ejecución diferente, basándose en la ejecución de una instrucción de finalización del acelerador; cuando se ha alcanzado el final del modo de ejecución diferente, restaurar los registros y las banderas desde el área de estado grabación; y cuando no se ha alcanzado el final del modo de ejecución diferente, actualizar el almacenamiento local con los resultados intermedios.
En un ejemplo, durante la ejecución en modo diferente y relajado ocurre uno o más de lo siguiente: se ignora el código que se modifica a sí mismo, se debilitan las restricciones del modelo de consistencia de la memoria, se altera la semántica de la coma flotante, se modifica la monitorización del rendimiento y se altera el uso de las banderas arquitectónicas.
En un ejemplo, el modo de ejecución diferente se introduce basándose en la ejecución de una instrucción de inicio del acelerador.
En un ejemplo, el modo de ejecución diferente se introduce basándose en un patrón determinado.
En un ejemplo, el tamaño y el formato del área de grabación de estado que va a almacenar los registros que se modificarán después de que se ejecute una instrucción de inicio del acelerador se define en un bloque de memoria apuntado por la instrucción de inicio del acelerador.
En un ejemplo, el método incluye, además: traducir el hilo o una parte del mismo antes de la ejecución.
En un ejemplo, el hilo o una parte del mismo se traduce en un código acelerador
En un ejemplo, el hilo traducido o la parte traducida del hilo se ejecuta por un acelerador.
En un ejemplo, una instrucción del bloque se rastrea actualizando un número de secuencia en un bloque de memoria asociado a dicho bloque del hilo.
En un ejemplo, se actualiza un número de secuencia del bloque del hilo, ya que una instrucción se ejecuta con éxito y se retira.
En un ejemplo, se ha alcanzado el fin del modo de ejecución diferente cuando se ejecuta y se retira una instrucción de fin de acelerador.
En un ejemplo, cuando no se ha alcanzado el fin del modo de ejecución diferente determinado por la ejecución de una instrucción de finalización del acelerador, se intenta utilizar los resultados intermedios para intentar ejecutar partes del bloque.
En un ejemplo, se usa un elemento de procesamiento no del acelerador para ejecutar con los resultados intermedios después de una excepción o interrupción.
En un ejemplo, cuando no se ha alcanzado el fin del modo de ejecución diferente, se hace retroceder la ejecución a un punto en el que se inició el uso del acelerador.
En un ejemplo, un sistema incluye: un decodificador para decodificar una instrucción que tiene un código de operación, un campo para un primer operando de origen de datos empaquetados, uno o más campos para los operandos de origen de datos empaquetados del segundo a N, y un campo para un operando de destino de datos empaquetados; un circuito de ejecución para ejecutar la instrucción decodificada para, para cada posición de elemento de datos empaquetados de los operandos de origen de datos empaquetados del segundo a N, 1) multiplicar un elemento de datos de esa posición de elemento de datos empaquetados de ese operando de origen de datos empaquetados por un elemento de datos de una posición de elemento de datos empaquetados correspondiente del primer operando de origen de datos empaquetados para generar un resultado temporal, 2) sumar los resultados temporales, 3) añadir la suma de los resultados temporales a un elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados, y 4) almacenar la suma de los resultados temporales a un elemento de datos de la posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados en la posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados.
En un ejemplo, N se indica con el código de operación.
En un ejemplo, los valores de los operandos de origen se copian en los registros de una matriz de multiplicaciónadición.
En un ejemplo, el circuito de ejecución incluye una red de reducción de árbol binario.
En un ejemplo, el circuito de ejecución es una parte de un acelerador.
En un ejemplo, la red de reducción de árbol binario comprende una pluralidad de circuitos de multiplicación acoplados a un primer conjunto de circuitos de suma en pares, de tal manera que el primer conjunto de circuitos de suma está acoplado a un segundo conjunto de circuitos de suma que está acoplado a un tercer conjunto de circuitos de suma que también está acoplado al elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados.
En un ejemplo, cada multiplicación se procesa en paralelo.
En un ejemplo, los elementos de datos empaquetados corresponden a elementos de una o más matrices.
En un ejemplo, un método incluye: decodificar una instrucción que tiene un código de operación, un campo para un primer operando de origen de datos empaquetados, uno o más campos para los operandos de origen de datos empaquetados del segundo a N, y un campo para un operando de destino de datos empaquetados; ejecutar la instrucción decodificada para, para cada posición de elemento de datos empaquetados de los operandos de origen de datos empaquetados del segundo a N, 1) multiplicar un elemento de datos de esa posición de elemento de datos empaquetados de ese operando de origen de datos empaquetados por un elemento de datos de una posición de elemento de datos empaquetados correspondiente del primer operando de origen de datos empaquetados para generar un resultado temporal, 2) sumar los resultados temporales, 3) añadir la suma de los resultados temporales a un elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados, y 4) almacenar la suma de los resultados temporales a un elemento de datos de la posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados en la posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados.
En un ejemplo, N se indica con el código de operación.
En un ejemplo, los valores de los operandos de origen se copian en los registros de una matriz de multiplicaciónadición.
En un ejemplo, el circuito de ejecución incluye una red de reducción de árbol binario.
En un ejemplo, la red de reducción de árbol binario comprende una pluralidad de circuitos de multiplicación acoplados a un primer conjunto de circuitos de suma en pares, de tal manera que el primer conjunto de circuitos de suma está acoplado a un segundo conjunto de circuitos de suma que está acoplado a un tercer conjunto de circuitos de suma que también está acoplado al elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados.
En un ejemplo, cada operando de datos empaquetados tiene ocho elementos de datos empaquetados.
En un ejemplo, cada multiplicación se procesa en paralelo.
En un ejemplo, los elementos de datos empaquetados corresponden a elementos de una o más matrices.
En un ejemplo, un medio no transitorio legible por máquina almacena una instrucción que, cuando se ejecuta por un procesador, hace que el procesador realice un método, incluyendo el método: decodificar una instrucción que tiene un código de operación, un campo para un primer operando de origen de datos empaquetados, uno o más campos para los operandos de origen de datos empaquetados del segundo a N, y un campo para un operando de destino de datos empaquetados; ejecutar la instrucción decodificada para, para cada posición de elemento de datos empaquetados de los operandos de origen de datos empaquetados del segundo a N, 1) multiplicar un elemento de datos de esa posición de elemento de datos empaquetados de ese operando de origen de datos empaquetados por un elemento de datos de una posición de elemento de datos empaquetados correspondiente del primer operando de origen de datos empaquetados para generar un resultado temporal, 2) sumar los resultados temporales, 3) añadir la suma de los resultados temporales a un elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados, y 4) almacenar la suma de los resultados temporales a un elemento de datos de la posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados en la posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados.
En un ejemplo, N se indica con el código de operación.
En un ejemplo, los valores de los operandos de origen se copian en los registros de una matriz de multiplicaciónadición.
En un ejemplo, el circuito de ejecución incluye una red de reducción de árbol binario.
En un ejemplo, la red de reducción de árbol binario comprende una pluralidad de circuitos de multiplicación acoplados a un primer conjunto de circuitos de suma en pares, de tal manera que el primer conjunto de circuitos de suma está acoplado a un segundo conjunto de circuitos de suma que está acoplado a un tercer conjunto de circuitos de suma que también está acoplado al elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados.
En un ejemplo, cada operando de datos empaquetados tiene ocho elementos de datos empaquetados.
En un ejemplo, cada multiplicación se procesa en paralelo.
En un ejemplo, los elementos de datos empaquetados corresponden a elementos de una o más matrices.
En un ejemplo, un método incluye: decodificar una instrucción que tiene un código de operación, un campo para un primer operando de origen de datos empaquetados, uno o más campos para los operandos de registro de origen de datos empaquetados del segundo a N, y un campo para un operando de destino de datos empaquetados; ejecutar la instrucción decodificada para, para cada posición de elemento de datos empaquetados de los operandos de origen de datos empaquetados del segundo a N, 1) multiplicar un elemento de datos de esa posición de elemento de datos empaquetados de ese operando de origen de datos empaquetados por un elemento de datos de una posición de elemento de datos empaquetados correspondiente del primer operando de origen de datos empaquetados para generar un resultado temporal, 2) sumar los resultados temporales en pares, 3) añadir la suma de los resultados temporales a un elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados, y 4) almacenar la suma de los resultados temporales a un elemento de datos de la posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados.
En un ejemplo, N se indica con el código de operación.
En un ejemplo, los valores de los operandos de origen se copian en los registros de una matriz de multiplicaciónadición.
En un ejemplo, el circuito de ejecución es una red de reducción de árboles binarios.
En un ejemplo, la red de reducción de árbol binario comprende una pluralidad de circuitos de multiplicación acoplados a un primer conjunto de circuitos de suma en pares, de tal manera que el primer conjunto de circuitos de suma está acoplado a un segundo conjunto de circuitos de suma que está acoplado a un tercer conjunto de circuitos de suma que también está acoplado al elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados.
En un ejemplo, cada operando de datos empaquetados tiene ocho elementos de datos empaquetados.
En un ejemplo, cada multiplicación se procesa en paralelo.
En un ejemplo, un medio no transitorio legible por máquina almacena una instrucción que, cuando se ejecuta por un procesador, hace que el procesador realice un método, incluyendo el método: decodificar una instrucción que tiene un código de operación, un campo para un primer operando de origen de datos empaquetados, uno o más campos para los operandos de registro de origen de datos empaquetados del segundo a N, y un campo para un operando de destino de datos empaquetados; ejecutar la instrucción decodificada para, para cada posición de elemento de datos empaquetados de los operandos de origen de datos empaquetados del segundo a N, 1) multiplicar un elemento de datos de esa posición de elemento de datos empaquetados de ese operando de origen de datos empaquetados por un elemento de datos de una posición de elemento de datos empaquetados correspondiente del primer operando de origen de datos empaquetados para generar un resultado temporal, 2) sumar los resultados temporales en pares, 3) añadir la suma de los resultados temporales a un elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados, y 4) almacenar la suma de los resultados temporales a un elemento de datos de la posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados.
En un ejemplo, N se indica con el código de operación.
En un ejemplo, los valores de los operandos de origen se copian en los registros de una matriz de multiplicaciónadición.
En un ejemplo, el circuito de ejecución es una red de reducción de árboles binarios.
En un ejemplo, la red de reducción de árbol binario comprende una pluralidad de circuitos de multiplicación acoplados a un primer conjunto de circuitos de suma en pares, de tal manera que el primer conjunto de circuitos de suma está acoplado a un segundo conjunto de circuitos de suma que está acoplado a un tercer conjunto de circuitos de suma que también está acoplado al elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados.
En un ejemplo, cada operando de datos empaquetados tiene ocho elementos de datos empaquetados.
En un ejemplo, cada multiplicación se procesa en paralelo.
En un ejemplo, un sistema incluye: un decodificador para decodificar una instrucción que tiene un código de operación, un campo para un primer operando de origen de datos empaquetados, uno o más campos para los operandos de registro de origen de datos empaquetados del segundo a N, y un campo para un operando de destino de datos empaquetados; circuitos de ejecución para ejecutar la instrucción decodificada para, para cada posición de elemento de datos empaquetados de los operandos de origen de datos empaquetados del segundo a N, 1) multiplicar un elemento de datos de esa posición de elemento de datos empaquetados de ese operando de origen de datos empaquetados por un elemento de datos de una posición de elemento de datos empaquetados correspondiente del primer operando de origen de datos empaquetados para generar un resultado temporal, 2) sumar los resultados temporales en pares, 3) añadir la suma de los resultados temporales a un elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados, y 4) almacenar la suma de los resultados temporales a un elemento de datos de la posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados.
En un ejemplo, N se indica con el código de operación.
En un ejemplo, los valores de los operandos de origen se copian en los registros de una matriz de multiplicaciónadición.
En un ejemplo, el circuito de ejecución es una red de reducción de árboles binarios.
En un ejemplo, la red de reducción de árbol binario comprende una pluralidad de circuitos de multiplicación acoplados a un primer conjunto de circuitos de suma en pares, de tal manera que el primer conjunto de circuitos de suma está acoplado a un segundo conjunto de circuitos de suma que está acoplado a un tercer conjunto de circuitos de suma que también está acoplado al elemento de datos de una posición de elemento de datos empaquetados correspondiente del operando de destino de datos empaquetados.
En un ejemplo, cada operando de datos empaquetados tiene ocho elementos de datos empaquetados.
En un ejemplo, cada multiplicación se procesa en paralelo.
En un ejemplo, un sistema incluye: un acelerador que incluye una interfaz de bus multiprotocolo para acoplar el acelerador a un procesador anfitrión, incluyendo el acelerador uno o más elementos de procesamiento para procesar comandos; una cola de trabajo compartida que incluye una pluralidad de entradas para almacenar los descriptores de trabajo enviados por una pluralidad de clientes, incluyendo un descriptor de trabajo un código de identificación para identificar a un cliente que envió el descriptor de trabajo, al menos un comando que debe ser ejecutado por el o los elementos de procesamiento, e información de direccionamiento; un árbitro para despachar descriptores de trabajo desde la cola de trabajo compartida, de acuerdo con una política de arbitraje especificada, a uno o más elementos de procesamiento, de manera que cada uno de los uno o más elementos de procesamiento reciba los descriptores de trabajo despachados desde el árbitro, para realizar traducciones de direcciones de origen y de destino, lea los datos de origen identificados por las traducciones de direcciones de origen, ejecute el al menos un comando para generar datos de destino, y escriba los datos de destino en una memoria usando la traducción de direcciones de destino. En un ejemplo, la pluralidad de clientes comprende una o más aplicaciones en modo usuario que envían solicitudes directas de entrada/salida (ES) en modo usuario al acelerador; controladores en modo de núcleo que se ejecutan en máquinas virtuales (VM) que comparten el acelerador; y/o agentes de software que se ejecutan en múltiples contenedores.
En un ejemplo, al menos un cliente de la pluralidad de clientes comprende una aplicación en modo usuario o un contenedor ejecutado dentro de una VM.
En un ejemplo, los clientes comprenden uno o más de los agentes de entrada/salida (ES) de pares y/o solicitudes de descarga encadenadas por software.
En un ejemplo, al menos uno de los agentes de ES de pares comprende un controlador de interfaz de red (NIC). En un ejemplo, el sistema incluye, además: una caché de traducción de direcciones para almacenar traducciones de direcciones virtuales a físicas utilizables por el o los elementos de procesamiento.
En un ejemplo, la política de arbitraje especificada comprende una política de primero en entrar, primero en salir. En un ejemplo, la política de arbitraje especificada comprende una política de calidad de servicio (QoS) en la que los descriptores de trabajo de un primer cliente tienen prioridad sobre los descriptores de trabajo de un segundo cliente. En un ejemplo, un descriptor de trabajo del primer cliente debe enviarse a uno o más elementos de procesamiento antes que un descriptor de trabajo del segundo cliente, incluso si el descriptor de trabajo del segundo cliente se recibe en la cola de trabajo compartida antes que el descriptor de trabajo del primer cliente.
En un ejemplo, el código de identificación comprende un identificador de espacio de direcciones de proceso (PASID) para identificar un espacio de direcciones en la memoria del sistema asignado al cliente.
En un ejemplo, el sistema incluye, además: una o más colas de trabajo especializadas, incluyendo cada cola de trabajo especializada una pluralidad de entradas para almacenar descriptores de trabajo enviados por un solo cliente asociado a la cola de trabajo especializada.
En un ejemplo, el sistema incluye, además: un registro de configuración de grupo que se programará para combinar dos o más de las colas de trabajo especializadas y/o colas de trabajo compartidas en un grupo, el grupo que se asociará con uno o más de los elementos de procesamiento.
En un ejemplo, los uno o más elementos de procesamiento van a procesar descriptores de trabajo de las colas de trabajo especializadas y/o de las colas de trabajo compartidas en el grupo.
En un ejemplo, un primer protocolo soportado por la interfaz de bus multiprotocolo comprende un protocolo de interfaz de memoria que se usará para acceder a un espacio de direcciones de memoria del sistema.
En un ejemplo, un segundo protocolo soportado por la interfaz de bus multiprotocolo comprende un protocolo de coherencia de caché para mantener la coherencia entre los datos almacenados en una memoria local del acelerador y un subsistema de memoria del procesador anfitrión que incluye una jerarquía de caché anfitrión y memoria de sistema.
En un ejemplo, un tercer protocolo soportado por la interfaz de bus multiprotocolo comprende un protocolo de enlace en serie que soporta el descubrimiento de dispositivos, el acceso a registros, la configuración, la inicialización, las interrupciones, el acceso directo a la memoria y los servicios de traducción de direcciones.
En un ejemplo, el tercer protocolo comprende el protocolo de interfaz express de componentes periféricos (PCIe). En un ejemplo, el sistema incluye, además: una memoria del acelerador para almacenar los datos de origen que van a ser procesados por los elementos de procesamiento y para almacenar los datos de destino resultantes del procesamiento por el uno o más elementos de procesamiento.
En un ejemplo, la memoria del acelerador comprende una memoria de alto ancho de banda (HBM).
En un ejemplo, a la memoria del acelerador se le asigna una primera porción de un espacio de direcciones de memoria del sistema usado por el procesador anfitrión.
En un ejemplo, el sistema incluye, además: una memoria de anfitrión que tiene asignada una segunda porción del espacio de direcciones de la memoria del sistema.
En un ejemplo, el sistema incluye, además: circuitos y/o lógica de polarización para indicar, para cada bloque de datos almacenado en el espacio de direcciones de la memoria del sistema, si los datos contenidos en el bloque están polarizados hacia el acelerador.
En un ejemplo, cada bloque de datos comprende una página de memoria.
En un ejemplo, el anfitrión debe abstenerse de procesar los datos que se polarizan hacia el acelerador sin transmitir en primer lugar una solicitud al acelerador.
En un ejemplo, los circuitos y/o la lógica de polarización incluyen una tabla de polarización que incluye un bit que se establece por bloque de datos de tamaño fijo para indicar una polarización hacia el acelerador.
En un ejemplo, el acelerador comprende: un controlador de memoria para comunicarse con los controladores de coherencia del procesador anfitrión para realizar una o más transacciones de coherencia de datos asociadas con los datos almacenados en la memoria del acelerador.
En un ejemplo, el controlador de memoria debe operar en un modo de polarización de dispositivo para acceder a los bloques de datos almacenados en la memoria del acelerador que se establecen en una polarización hacia el acelerador, de tal manera que cuando está en el modo de polarización de dispositivo, el controlador de memoria debe acceder a la memoria del acelerador sin consultar un controlador de coherencia de caché del procesador anfitrión. En un ejemplo, el controlador de memoria debe operar en un modo de polarización de anfitrión para acceder a los bloques de datos que se establecen en una polarización hacia el procesador de anfitrión, de tal manera que cuando está en el modo de polarización de anfitrión, el controlador de memoria va a enviar todas las solicitudes a la memoria del acelerador a través de un controlador de coherencia de caché en el procesador de anfitrión.
En un ejemplo, la cola de trabajo compartida debe almacenar al menos un descriptor de lote, que identifica un lote de descriptores de trabajo.
En un ejemplo, el sistema incluye, además: un circuito de procesamiento de lotes para procesar los descriptores de lotes leyendo el lote de descriptores de trabajo de la memoria.
En un ejemplo, un descriptor de trabajo debe añadirse a la cola de trabajo especializada en respuesta al procesador anfitrión que ejecuta un primer tipo de instrucción y de tal manera que el descriptor de trabajo debe añadirse a la cola de trabajo compartida en respuesta al procesador anfitrión que ejecuta un segundo tipo de instrucción.
En un ejemplo, un método incluye: colocar un primer conjunto de páginas de memoria en una polarización del dispositivo; asignar el primer conjunto de páginas de memoria desde una memoria local de un dispositivo acelerador acoplado a un procesador anfitrión; transferir datos de operandos a las páginas asignadas desde un núcleo del procesador anfitrión o un agente de entrada/salida; procesar los operandos por el dispositivo acelerador usando la memoria local para generar resultados; y convertir el primer conjunto de páginas de memoria del polarización del dispositivo a una polarización del anfitrión.
En un ejemplo, la colocación del primer conjunto de páginas de memoria en una polarización de dispositivo comprende la actualización para el primer conjunto de páginas de memoria en una tabla de polarización para indicar que las páginas están en polarización de dispositivo acelerador.
En un ejemplo, la actualización de las entradas comprende la configuración de un bit asociado a cada página del primer conjunto de páginas de memoria.
En un ejemplo, una vez establecida la polarización del dispositivo, se garantiza que el primer conjunto de páginas de memoria no se almacena en la memoria caché del anfitrión.
En un ejemplo, la asignación del primer conjunto de páginas de memoria comprende el inicio de una llamada al controlador o a la interfaz de programación de aplicaciones (API).
En un ejemplo, para procesar los operandos, el dispositivo acelerador ejecuta comandos y procesa datos directamente desde su memoria local.
En un ejemplo, la transferencia de datos de operandos a las páginas asignadas comprende el envío de uno o más descriptores de trabajo al dispositivo acelerador, identificando o incluyendo los descriptores de trabajo los operandos. En un ejemplo, los uno o más descriptores de trabajo pueden hacer que las páginas asignadas se descarguen de la caché del procesador anfitrión tras un comando.
En un ejemplo, se permite que el procesador anfitrión acceda, almacene en caché y comparta los resultados cuando el primer conjunto de páginas de memoria se establece a la polarización del anfitrión.

Claims (15)

REIVINDICACIONES
1. Un sistema, que comprende:
una pluralidad de elementos de procesamiento heterogéneos (103-109);
un planificador heterogéneo de hardware (101) para despachar instrucciones para su ejecución en uno o más de la pluralidad de elementos de procesamiento heterogéneos (103-109), correspondiendo las instrucciones a un fragmento de código que va a ser procesado por el uno o más de la pluralidad de elementos de procesamiento heterogéneos (103-109),
caracterizado por que
el planificador heterogéneo (101) traduce el fragmento de código a un formato correspondiente a un tipo de elemento de procesamiento heterogéneo seleccionado (103-109) usando uno o más convertidores para generar instrucciones que son instrucciones nativas para al menos uno del uno o más de la pluralidad de elementos de procesamiento heterogéneos (103-109).
2. El sistema de la reivindicación 1, en donde la pluralidad de elementos de procesamiento heterogéneos (103-109) comprende un núcleo de procesador en orden, un núcleo de procesador fuera de orden y un núcleo de procesador de datos empaquetados.
3. El sistema de la reivindicación 2, en donde la pluralidad de elementos de procesamiento heterogéneos (103-109) además comprende un acelerador (109), siendo el acelerador (109) un dispositivo de hardware que realiza funciones de manera más eficiente que los otros elementos de procesamiento heterogéneos.
4. El sistema de cualquiera de las reivindicaciones 1-3, en donde el planificador heterogéneo de hardware (101) además comprende:
un detector de fase de programa (313) para detectar una fase de programa del fragmento de código;
en donde la pluralidad de elementos de procesamiento heterogéneos (103-109) incluye un primer elemento de procesamiento que tiene una primera microarquitectura y un segundo elemento de procesamiento que tiene una segunda microarquitectura diferente de la primera microarquitectura;
en donde la fase de programa es una de una pluralidad de fases de programa, incluyendo una primera fase y una segunda fase y el despacho de instrucciones está basado en parte en la fase de programa detectada; y en donde el procesamiento del fragmento de código por el primer elemento de procesamiento es para producir características de rendimiento por vatio mejoradas en comparación con el procesamiento del fragmento de código por el segundo elemento de procesamiento.
5. El sistema de cualquiera de las reivindicaciones 1-4, en donde el planificador heterogéneo de hardware (101) además comprende:
un selector (309) para seleccionar un tipo de elemento de procesamiento de la pluralidad de elementos de procesamiento para ejecutar el fragmento de código recibido y planificar el fragmento de código en un elemento de procesamiento del tipo de elementos de procesamiento seleccionado mediante el despacho.
6. El sistema de la reivindicación 1, en donde el fragmento de código es una o más instrucciones asociadas a un hilo de software.
7. El sistema de cualquiera de las reivindicaciones 5-6, en donde para una fase de programa paralelo de datos, el tipo de elemento de procesamiento seleccionado es un núcleo de procesamiento para ejecutar instrucciones de una sola instrucción, múltiples datos (SIMD).
8. El sistema de cualquiera de las reivindicaciones 5-7, en donde para una fase de programa paralelo de datos, el tipo de elemento de procesamiento seleccionado son circuitos para soportar primitivas aritméticas densas.
9. El sistema de cualquiera de las reivindicaciones 5-7, en donde para una fase de programa paralelo de datos, el tipo de elemento de procesamiento seleccionado es un acelerador.
10. El sistema de cualquiera de las reivindicaciones 5-9, en donde una fase de programa paralelo de datos comprende elementos de datos que se procesan simultáneamente usando un mismo flujo de control.
11. El sistema de cualquiera de las reivindicaciones 5-10, en donde para una fase de programa paralelo de hilos, el tipo de elemento de procesamiento seleccionado es un núcleo de procesamiento escalar.
12. El sistema de cualquiera de las reivindicaciones 5-11, en donde una fase de programa paralela de hilos comprende ramales dependientes de datos que usan flujos de control únicos.
13. El sistema de cualquiera de las reivindicaciones 2-12, en donde para una fase de programa en serie el tipo de elemento de procesamiento seleccionado es un núcleo fuera de orden.
14. El sistema de cualquiera de las reivindicaciones 2-13, en donde para una fase de programa paralelo de datos, el tipo de elemento de procesamiento seleccionado es un núcleo de procesamiento para ejecutar instrucciones de una sola instrucción, múltiples datos (SIMD).
15. El sistema de cualquiera de las reivindicaciones 5-14, en donde el planificador heterogéneo de hardware (101) es para emular la funcionalidad cuando el tipo de elemento de procesamiento seleccionado no puede manejar nativamente el fragmento de código.
ES16925260T 2016-12-31 2016-12-31 Sistemas, métodos y aparatos para informática heterogénea Active ES2933675T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2016/069640 WO2018125250A1 (en) 2016-12-31 2016-12-31 Systems, methods, and apparatuses for heterogeneous computing

Publications (1)

Publication Number Publication Date
ES2933675T3 true ES2933675T3 (es) 2023-02-13

Family

ID=62709975

Family Applications (2)

Application Number Title Priority Date Filing Date
ES20207505T Active ES2974451T3 (es) 2016-12-31 2016-12-31 Sistemas, métodos y aparatos para informática heterogénea
ES16925260T Active ES2933675T3 (es) 2016-12-31 2016-12-31 Sistemas, métodos y aparatos para informática heterogénea

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES20207505T Active ES2974451T3 (es) 2016-12-31 2016-12-31 Sistemas, métodos y aparatos para informática heterogénea

Country Status (13)

Country Link
US (4) US11416281B2 (es)
EP (5) EP4089531B1 (es)
JP (1) JP6988040B2 (es)
KR (4) KR20220090588A (es)
CN (4) CN112506568A (es)
BR (1) BR112019010679A2 (es)
DE (1) DE112016007566T5 (es)
DK (1) DK3812900T3 (es)
ES (2) ES2974451T3 (es)
FI (1) FI3812900T3 (es)
PL (2) PL3812900T3 (es)
TW (4) TW202347124A (es)
WO (1) WO2018125250A1 (es)

Families Citing this family (271)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2538754B (en) * 2015-05-27 2018-08-29 Displaylink Uk Ltd Single-chip multi-processor communication
US10720195B2 (en) * 2015-09-25 2020-07-21 Intel Corporation Efficient memory activation at runtime
US11455190B2 (en) 2016-02-05 2022-09-27 Sas Institute Inc. Implicit status in many task computing
WO2017138220A1 (ja) * 2016-02-12 2017-08-17 ソニー株式会社 情報処理方法および情報処理装置
US10275243B2 (en) 2016-07-02 2019-04-30 Intel Corporation Interruptible and restartable matrix multiplication instructions, processors, methods, and systems
FR3060792B1 (fr) * 2016-12-19 2018-12-07 Safran Electronics & Defense Dispositif de chargement de donnees dans des unites informatiques de traitement depuis une source de donnees
US10884970B2 (en) * 2016-12-28 2021-01-05 Intel Corporation Techniques for coalescing doorbells in a request message
US11182315B2 (en) * 2017-02-10 2021-11-23 Intel Corporation Apparatuses, methods, and systems for hardware control of processor performance levels
US11099880B2 (en) * 2017-02-22 2021-08-24 Intel Corporation Virtualization of process address space identifiers for scalable virtualization of input/output devices
WO2018174931A1 (en) 2017-03-20 2018-09-27 Intel Corporation Systems, methods, and appartus for tile configuration
WO2018176360A1 (en) 2017-03-31 2018-10-04 Intel Corporation Scalable interrupt virtualization for input/output devices
US10474458B2 (en) 2017-04-28 2019-11-12 Intel Corporation Instructions and logic to perform floating-point and integer operations for machine learning
US20180329855A1 (en) * 2017-05-12 2018-11-15 Intel Corporation Alternate protocol negotiation in a high performance interconnect
WO2018213598A1 (en) * 2017-05-17 2018-11-22 Google Llc Special purpose neural network training chip
US11210133B1 (en) * 2017-06-12 2021-12-28 Pure Storage, Inc. Workload mobility between disparate execution environments
US12061822B1 (en) 2017-06-12 2024-08-13 Pure Storage, Inc. Utilizing volume-level policies in a storage system
US12086650B2 (en) 2017-06-12 2024-09-10 Pure Storage, Inc. Workload placement based on carbon emissions
US11989429B1 (en) 2017-06-12 2024-05-21 Pure Storage, Inc. Recommending changes to a storage system
US12086651B2 (en) 2017-06-12 2024-09-10 Pure Storage, Inc. Migrating workloads using active disaster recovery
US11080131B2 (en) * 2017-06-19 2021-08-03 Yissum Research Development Company Of The Hebrew University Of Jerusalem Ltd. High performance method and system for performing fault tolerant matrix multiplication
WO2019009870A1 (en) 2017-07-01 2019-01-10 Intel Corporation SAVE BACKGROUND TO VARIABLE BACKUP STATUS SIZE
CN112214726B (zh) * 2017-07-07 2024-05-03 华为技术有限公司 运算加速器
US10489195B2 (en) * 2017-07-20 2019-11-26 Cisco Technology, Inc. FPGA acceleration for serverless computing
US11005771B2 (en) 2017-10-16 2021-05-11 Mellanox Technologies, Ltd. Computational accelerator for packet payload operations
US11502948B2 (en) 2017-10-16 2022-11-15 Mellanox Technologies, Ltd. Computational accelerator for storage operations
CN107807843B (zh) * 2017-10-26 2019-05-24 北京百度网讯科技有限公司 虚拟机中的i/o请求处理方法、设备及计算机可读介质
US10698472B2 (en) * 2017-10-27 2020-06-30 Advanced Micro Devices, Inc. Instruction subset implementation for low power operation
US10708240B2 (en) 2017-12-14 2020-07-07 Mellanox Technologies, Ltd. Offloading communication security operations to a network interface controller
US11789729B2 (en) 2017-12-29 2023-10-17 Intel Corporation Systems and methods for computing dot products of nibbles in two tile operands
WO2019132976A1 (en) 2017-12-29 2019-07-04 Intel Corporation Unified address translation for virtualization of input/output devices
US11093247B2 (en) 2017-12-29 2021-08-17 Intel Corporation Systems and methods to load a tile register pair
US11669326B2 (en) 2017-12-29 2023-06-06 Intel Corporation Systems, methods, and apparatuses for dot product operations
US11816483B2 (en) 2017-12-29 2023-11-14 Intel Corporation Systems, methods, and apparatuses for matrix operations
US11023235B2 (en) 2017-12-29 2021-06-01 Intel Corporation Systems and methods to zero a tile register pair
US11809869B2 (en) 2017-12-29 2023-11-07 Intel Corporation Systems and methods to store a tile register pair to memory
US10599596B2 (en) * 2018-01-08 2020-03-24 Intel Corporation Management of processor performance based on user interrupts
KR102228586B1 (ko) * 2018-01-19 2021-03-16 한국전자통신연구원 Gpu 기반의 적응적 blas 연산 가속화 장치 및 방법
US11231927B2 (en) * 2018-03-08 2022-01-25 Intel Corporation System, apparatus and method for providing a fabric for an accelerator
US10664287B2 (en) 2018-03-30 2020-05-26 Intel Corporation Systems and methods for implementing chained tile operations
US11429725B1 (en) * 2018-04-26 2022-08-30 Citicorp Credit Services, Inc. (Usa) Automated security risk assessment systems and methods
US10877766B2 (en) * 2018-05-24 2020-12-29 Xilinx, Inc. Embedded scheduling of hardware resources for hardware acceleration
US11144357B2 (en) * 2018-05-25 2021-10-12 International Business Machines Corporation Selecting hardware accelerators based on score
US11294678B2 (en) 2018-05-29 2022-04-05 Advanced Micro Devices, Inc. Scheduler queue assignment
US11222138B2 (en) * 2018-05-29 2022-01-11 Visa International Service Association Privacy-preserving machine learning in the three-server model
CN112352234B (zh) * 2018-06-15 2024-03-08 华为云计算技术有限公司 用于处理并发属性图查询的系统
US11036645B2 (en) * 2018-06-26 2021-06-15 Red Hat, Inc. Secure userspace networking for guests
US11093605B2 (en) * 2018-06-28 2021-08-17 Cisco Technology, Inc. Monitoring real-time processor instruction stream execution
US11360809B2 (en) * 2018-06-29 2022-06-14 Intel Corporation Multithreaded processor core with hardware-assisted task scheduling
CN110825485A (zh) * 2018-08-07 2020-02-21 华为技术有限公司 数据处理的方法、设备和服务器
US10423558B1 (en) 2018-08-08 2019-09-24 Apple Inc. Systems and methods for controlling data on a bus using latency
US10970055B2 (en) * 2018-08-21 2021-04-06 International Business Machines Corporation Identifying software and hardware bottlenecks
US10942768B2 (en) * 2018-08-29 2021-03-09 Red Hat, Inc. Computing task scheduling in a computer system utilizing efficient attributed priority queues
US11093579B2 (en) 2018-09-05 2021-08-17 Intel Corporation FP16-S7E8 mixed precision for deep learning and other algorithms
US10782918B2 (en) * 2018-09-06 2020-09-22 Advanced Micro Devices, Inc. Near-memory data-dependent gather and packing
US10977198B2 (en) * 2018-09-12 2021-04-13 Micron Technology, Inc. Hybrid memory system interface
US11579883B2 (en) 2018-09-14 2023-02-14 Intel Corporation Systems and methods for performing horizontal tile operations
US10970076B2 (en) 2018-09-14 2021-04-06 Intel Corporation Systems and methods for performing instructions specifying ternary tile logic operations
US10719323B2 (en) 2018-09-27 2020-07-21 Intel Corporation Systems and methods for performing matrix compress and decompress instructions
US10990396B2 (en) 2018-09-27 2021-04-27 Intel Corporation Systems for performing instructions to quickly convert and use tiles as 1D vectors
US10866786B2 (en) 2018-09-27 2020-12-15 Intel Corporation Systems and methods for performing instructions to transpose rectangular tiles
US10896043B2 (en) 2018-09-28 2021-01-19 Intel Corporation Systems for performing instructions for fast element unpacking into 2-dimensional registers
US10963256B2 (en) 2018-09-28 2021-03-30 Intel Corporation Systems and methods for performing instructions to transform matrices into row-interleaved format
US10929143B2 (en) 2018-09-28 2021-02-23 Intel Corporation Method and apparatus for efficient matrix alignment in a systolic array
US10949207B2 (en) * 2018-09-29 2021-03-16 Intel Corporation Processor core supporting a heterogeneous system instruction set architecture
US10963246B2 (en) 2018-11-09 2021-03-30 Intel Corporation Systems and methods for performing 16-bit floating-point matrix dot product instructions
US12008475B2 (en) 2018-11-14 2024-06-11 Nvidia Corporation Transposed sparse matrix multiply by dense matrix for neural network training
US10705993B2 (en) 2018-11-19 2020-07-07 Xilinx, Inc. Programming and controlling compute units in an integrated circuit
US10892944B2 (en) 2018-11-29 2021-01-12 International Business Machines Corporation Selecting and using a cloud-based hardware accelerator
CN109542832B (zh) * 2018-11-30 2020-09-01 青岛方寸微电子科技有限公司 一种无锁机制的异构多核cpu间通信系统及方法
US11340877B2 (en) * 2018-12-19 2022-05-24 Network Native, Inc. System and method for holistic application development and deployment in a distributed heterogeneous computing environment
US10929503B2 (en) 2018-12-21 2021-02-23 Intel Corporation Apparatus and method for a masked multiply instruction to support neural network pruning operations
US11886875B2 (en) 2018-12-26 2024-01-30 Intel Corporation Systems and methods for performing nibble-sized operations on matrix elements
US11294671B2 (en) 2018-12-26 2022-04-05 Intel Corporation Systems and methods for performing duplicate detection instructions on 2D data
US20200210517A1 (en) 2018-12-27 2020-07-02 Intel Corporation Systems and methods to accelerate multiplication of sparse matrices
US10922077B2 (en) 2018-12-29 2021-02-16 Intel Corporation Apparatuses, methods, and systems for stencil configuration and computation instructions
US10942985B2 (en) 2018-12-29 2021-03-09 Intel Corporation Apparatuses, methods, and systems for fast fourier transform configuration and computation instructions
TWI704460B (zh) * 2019-01-19 2020-09-11 神雲科技股份有限公司 叢集式系統中維持記憶體共享方法
US11385918B2 (en) * 2019-01-23 2022-07-12 Vmware, Inc. Dynamic discovery of internal kernel functions and global data
US11537504B2 (en) * 2019-01-28 2022-12-27 Xepic Corporation Limited Realization of functional verification debug station via cross-platform record-mapping-replay technology
TWI773959B (zh) 2019-01-31 2022-08-11 美商萬國商業機器公司 用於處理輸入輸出儲存指令之資料處理系統、方法及電腦程式產品
CN113366457B (zh) 2019-01-31 2024-06-14 国际商业机器公司 处理输入/输出存储指令
TWI767175B (zh) * 2019-01-31 2022-06-11 美商萬國商業機器公司 用於處理輸入輸出儲存指令之資料處理系統、方法及電腦程式產品
JP7379491B2 (ja) 2019-01-31 2023-11-14 インターナショナル・ビジネス・マシーンズ・コーポレーション 入出力ストア命令をハンドリングする方法、システム、およびプログラム
US11061728B2 (en) * 2019-02-12 2021-07-13 Western Digital Technologies, Inc. Systems and methods for heterogeneous address space allocation
WO2020190807A1 (en) * 2019-03-15 2020-09-24 Intel Corporation Systolic disaggregation within a matrix accelerator architecture
CN113396400A (zh) 2019-03-15 2021-09-14 英特尔公司 用于针对高速缓存操作提供层级开放划分扇区和可变扇区大小的系统和方法
US11934342B2 (en) 2019-03-15 2024-03-19 Intel Corporation Assistance for hardware prefetch in cache access
EP4130988A1 (en) 2019-03-15 2023-02-08 INTEL Corporation Systems and methods for cache optimization
US10942738B2 (en) * 2019-03-29 2021-03-09 Intel Corporation Accelerator systems and methods for matrix operations
US11762695B2 (en) * 2019-03-29 2023-09-19 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Transparent memory management for over-subscribed accelerators
US11016731B2 (en) 2019-03-29 2021-05-25 Intel Corporation Using Fuzzy-Jbit location of floating-point multiply-accumulate results
US11269630B2 (en) 2019-03-29 2022-03-08 Intel Corporation Interleaved pipeline of floating-point adders
US10990397B2 (en) 2019-03-30 2021-04-27 Intel Corporation Apparatuses, methods, and systems for transpose instructions of a matrix operations accelerator
US11175891B2 (en) 2019-03-30 2021-11-16 Intel Corporation Systems and methods to perform floating-point addition with selected rounding
US11184439B2 (en) * 2019-04-01 2021-11-23 Mellanox Technologies, Ltd. Communication with accelerator via RDMA-based network adapter
US11036649B2 (en) * 2019-04-04 2021-06-15 Cisco Technology, Inc. Network interface card resource partitioning
CN111782577B (zh) 2019-04-04 2023-03-24 安徽寒武纪信息科技有限公司 数据处理装置及方法以及相关产品
KR20210002518A (ko) * 2019-04-04 2021-01-08 캠브리콘 테크놀로지스 코퍼레이션 리미티드 데이터 처리방법과 장치 및 관련 제품
CN111831337B (zh) 2019-04-19 2022-11-29 安徽寒武纪信息科技有限公司 数据同步方法及装置以及相关产品
CN111782133A (zh) * 2019-04-04 2020-10-16 安徽寒武纪信息科技有限公司 数据处理方法及装置以及相关产品
US10963362B2 (en) * 2019-04-11 2021-03-30 Dell Products L.P. Method and system for identifying latency-sensitive computing workloads of information handling systems
US10970238B2 (en) 2019-04-19 2021-04-06 Intel Corporation Non-posted write transactions for a computer bus
CN111832736B (zh) * 2019-04-19 2024-04-12 伊姆西Ip控股有限责任公司 用于处理机器学习模型的方法、设备和计算机可读存储介质
CN113785269A (zh) * 2019-04-30 2021-12-10 惠普发展公司，有限责任合伙企业 引导处理器
US11086672B2 (en) * 2019-05-07 2021-08-10 International Business Machines Corporation Low latency management of processor core wait state
CN110175164B (zh) * 2019-05-27 2023-04-07 浪潮软件股份有限公司 一种SparkSQL thriftserver查询及操作Hive的权限控制的方法
US11403097B2 (en) 2019-06-26 2022-08-02 Intel Corporation Systems and methods to skip inconsequential matrix operations
US10929129B2 (en) * 2019-06-29 2021-02-23 Intel Corporation Apparatus and method for modifying addresses, data, or program code associated with offloaded instructions
US11030000B2 (en) 2019-06-29 2021-06-08 Intel Corporation Core advertisement of availability
US11372711B2 (en) 2019-06-29 2022-06-28 Intel Corporation Apparatus and method for fault handling of an offload transaction
US11016766B2 (en) 2019-06-29 2021-05-25 Intel Corporation Apparatus and method for compiler hints for inter-core offload
US11321144B2 (en) 2019-06-29 2022-05-03 Intel Corporation Method and apparatus for efficiently managing offload work between processing units
US11182208B2 (en) 2019-06-29 2021-11-23 Intel Corporation Core-to-core start “offload” instruction(s)
US10983796B2 (en) 2019-06-29 2021-04-20 Intel Corporation Core-to-core end “offload” instruction(s)
US11334647B2 (en) 2019-06-29 2022-05-17 Intel Corporation Apparatuses, methods, and systems for enhanced matrix multiplier architecture
US11249786B2 (en) * 2019-07-03 2022-02-15 Vmware, Inc. Virtualizing hardware components that implement AI applications
US11061681B2 (en) * 2019-07-25 2021-07-13 International Business Machines Corporation Instruction streaming using copy select vector
US11301254B2 (en) * 2019-07-25 2022-04-12 International Business Machines Corporation Instruction streaming using state migration
US11169737B2 (en) 2019-08-13 2021-11-09 Micron Technology, Inc. Speculation in memory
CN114258538B (zh) * 2019-08-16 2024-04-12 谷歌有限责任公司 片上操作的显式调度
US11294715B2 (en) 2019-08-28 2022-04-05 Marvell Asia Pte, Ltd. System and method for queuing work within a virtualized scheduler based on in-unit accounting of in-unit entries
US11221962B2 (en) * 2019-09-04 2022-01-11 Apple Inc. Unified address translation
CN110750265B (zh) * 2019-09-06 2021-06-11 华中科技大学 一种面向图计算的高层次综合方法及系统
US11915041B1 (en) * 2019-09-12 2024-02-27 Neureality Ltd. Method and system for sequencing artificial intelligence (AI) jobs for execution at AI accelerators
US11144290B2 (en) * 2019-09-13 2021-10-12 Huawei Technologies Co., Ltd. Method and apparatus for enabling autonomous acceleration of dataflow AI applications
US11409553B1 (en) * 2019-09-26 2022-08-09 Marvell Asia Pte, Ltd. System and method for isolating work within a virtualized scheduler using tag-spaces
US11748174B2 (en) * 2019-10-02 2023-09-05 Intel Corporation Method for arbitration and access to hardware request ring structures in a concurrent environment
CN110865814B (zh) * 2019-10-30 2021-11-16 上海天数智芯半导体有限公司 一种支持异构计算核架构的编译器实现方法和系统
US11861761B2 (en) 2019-11-15 2024-01-02 Intel Corporation Graphics processing unit processing and caching improvements
CN112835510B (zh) * 2019-11-25 2022-08-26 北京灵汐科技有限公司 一种片上存储资源存储格式的控制方法及装置
US11086804B2 (en) * 2019-12-09 2021-08-10 Western Digital Technologies, Inc. Storage system and method for reducing read-retry duration
US11334384B2 (en) * 2019-12-10 2022-05-17 Advanced Micro Devices, Inc. Scheduler queue assignment burst mode
US11127108B2 (en) * 2019-12-11 2021-09-21 Intel Corporation Sparse matrix optimization mechanism
CN114787830A (zh) * 2019-12-20 2022-07-22 惠普发展公司，有限责任合伙企业 异构集群中的机器学习工作负载编排
US11714875B2 (en) 2019-12-28 2023-08-01 Intel Corporation Apparatuses, methods, and systems for instructions of a matrix operations accelerator
CN111258923B (zh) * 2020-01-16 2023-03-14 重庆邮电大学 一种基于异构混合内存系统的页面分配方法
CN111262800B (zh) * 2020-01-19 2022-04-29 天津芯海创科技有限公司 一种以太网交换机的业务数据通信方法及系统
US11461483B2 (en) * 2020-01-28 2022-10-04 Intel Corporation Protection of communications between trusted execution environment and hardware accelerator utilizing enhanced end-to-end encryption and inter-context security
US11226816B2 (en) * 2020-02-12 2022-01-18 Samsung Electronics Co., Ltd. Systems and methods for data placement for in-memory-compute
US20210256092A1 (en) * 2020-02-19 2021-08-19 Nvidia Corporation Application programming interface to accelerate matrix operations
US11416581B2 (en) * 2020-03-09 2022-08-16 International Business Machines Corporation Multiplication of a matrix with an input vector
US11340942B2 (en) * 2020-03-19 2022-05-24 Raytheon Company Cooperative work-stealing scheduler
EP4128060A4 (en) * 2020-03-23 2024-04-24 Mentium Technologies Inc. DIGITAL-IMC HYBRID SYSTEM ARCHITECTURE FOR ACCELERATION OF A NEURAL NETWORK
US11080059B1 (en) * 2020-03-30 2021-08-03 Sandisk Technologies Llc Reducing firmware size and increasing firmware performance
US11188471B2 (en) 2020-04-03 2021-11-30 Alibaba Group Holding Limited Cache coherency for host-device systems
US11693795B2 (en) 2020-04-17 2023-07-04 Texas Instruments Incorporated Methods and apparatus to extend local buffer of a hardware accelerator
US11775298B2 (en) * 2020-04-24 2023-10-03 Intel Corporation Frequency scaling for per-core accelerator assignments
US12052370B2 (en) * 2020-05-04 2024-07-30 Intel Corporation Managing state in accelerators
CN111737176B (zh) * 2020-05-11 2022-07-15 瑞芯微电子股份有限公司 一种基于pcie数据的同步装置及驱动方法
US11789770B2 (en) 2020-05-19 2023-10-17 General Electric Company Systems and methods for creating surrogate models
JP2021189462A (ja) * 2020-05-25 2021-12-13 株式会社日立製作所 ストレージ装置
KR102418794B1 (ko) * 2020-06-02 2022-07-08 오픈엣지테크놀로지 주식회사 하드웨어 가속기를 위한 파라미터를 메모리로부터 액세스하는 방법 및 이를 이용한 장치
US11657007B2 (en) * 2020-06-15 2023-05-23 Rambus Inc. Remote memory selection
US11461099B2 (en) * 2020-06-25 2022-10-04 Intel Corporation System, apparatus and method for fine-grain address space selection in a processor
US11907744B2 (en) 2020-06-25 2024-02-20 Intel Corporation System, apparatus and method for enabling fine-grain quality of service or rate control for work submissions
US11669473B2 (en) * 2020-06-26 2023-06-06 Advanced Micro Devices, Inc. Allreduce enhanced direct memory access functionality
US11972230B2 (en) 2020-06-27 2024-04-30 Intel Corporation Matrix transpose and multiply
US12112167B2 (en) 2020-06-27 2024-10-08 Intel Corporation Matrix data scatter and gather between rows and irregularly spaced memory locations
CN111784489A (zh) * 2020-06-28 2020-10-16 广东金宇恒软件科技有限公司 一种基于大数据的财政核算管理系统
CN111752960B (zh) * 2020-06-28 2023-07-28 北京百度网讯科技有限公司 数据处理方法和装置
CN113867798A (zh) * 2020-06-30 2021-12-31 上海寒武纪信息科技有限公司 集成计算装置、集成电路芯片、板卡和计算方法
CN115878824B (zh) * 2020-07-07 2023-10-20 华为技术有限公司 图像检索系统、方法和装置
IL276538B2 (en) 2020-08-05 2023-08-01 Mellanox Technologies Ltd A cryptographic device for data communication
CN114095153A (zh) 2020-08-05 2022-02-25 迈络思科技有限公司 密码数据通信装置
US11321238B2 (en) * 2020-08-11 2022-05-03 Micron Technology, Inc. User process identifier based address translation
WO2022048762A1 (en) * 2020-09-04 2022-03-10 Huawei Technologies Co., Ltd. Devices and methods for remote direct memory access
US11947928B2 (en) 2020-09-10 2024-04-02 Hewlett Packard Enterprise Development Lp Multi-die dot-product engine to provision large scale machine learning inference applications
US11593356B2 (en) * 2020-09-11 2023-02-28 ForgeRock, Inc. Never stale caching of effective properties
US12086082B2 (en) * 2020-09-21 2024-09-10 Intel Corporation PASID based routing extension for scalable IOV systems
US11409685B1 (en) * 2020-09-24 2022-08-09 Amazon Technologies, Inc. Data synchronization operation at distributed computing system
US11467992B1 (en) 2020-09-24 2022-10-11 Amazon Technologies, Inc. Memory access operation in distributed computing system
US20220101179A1 (en) * 2020-09-25 2022-03-31 Advanced Micro Devices, Inc. Direct-connected machine learning accelerator
US11714559B2 (en) * 2020-09-25 2023-08-01 Advanced Micro Devices, Inc. Efficient memory-semantic networking using scoped memory models
US11941395B2 (en) 2020-09-26 2024-03-26 Intel Corporation Apparatuses, methods, and systems for instructions for 16-bit floating-point matrix dot product instructions
US11354258B1 (en) 2020-09-30 2022-06-07 Amazon Technologies, Inc. Control plane operation at distributed computing system
US20220101108A1 (en) * 2020-09-30 2022-03-31 International Business Machines Corporation Memory-mapped neural network accelerator for deployable inference systems
CN114326452B (zh) * 2020-10-10 2023-11-21 中国科学院沈阳自动化研究所 一种用于精密运动控制的异构计算加速方法
CN111966387B (zh) * 2020-10-22 2021-03-12 苏州浪潮智能科技有限公司 一种ntb卡的固件升级方法、装置、设备及存储介质
US11948000B2 (en) 2020-10-27 2024-04-02 Advanced Micro Devices, Inc. Gang scheduling for low-latency task synchronization
US11386034B2 (en) 2020-10-30 2022-07-12 Xilinx, Inc. High throughput circuit architecture for hardware acceleration
US20210240655A1 (en) * 2020-11-16 2021-08-05 Intel Corporation Source ordering in device interconnects
CN112506701B (zh) * 2020-12-02 2022-01-21 广东电网有限责任公司佛山供电局 一种基于三模lockstep的多处理器芯片错误恢复方法
US20220188606A1 (en) * 2020-12-14 2022-06-16 Micron Technology, Inc. Memory Configuration to Support Deep Learning Accelerator in an Integrated Circuit Device
US11836518B2 (en) * 2020-12-17 2023-12-05 Wave Computing, Inc. Processor graph execution using interrupt conservation
TWI792773B (zh) * 2020-12-18 2023-02-11 美商聖巴諾瓦系統公司 用於可重配置處理器即服務（ＲＰａａＳ）的節點內基於緩衝器的串流
US20220197816A1 (en) * 2020-12-22 2022-06-23 Intel Corporation Compressed cache memory with parallel decompress on fault
US12001887B2 (en) 2020-12-24 2024-06-04 Intel Corporation Apparatuses, methods, and systems for instructions for aligning tiles of a matrix operations accelerator
US12001385B2 (en) 2020-12-24 2024-06-04 Intel Corporation Apparatuses, methods, and systems for instructions for loading a tile of a matrix operations accelerator
TWI779444B (zh) * 2020-12-28 2022-10-01 瑞昱半導體股份有限公司 用於同步動態隨機存取記憶體之控制模組及其控制方法
US11960420B2 (en) * 2021-02-16 2024-04-16 Red Hat, Inc. Direct memory control operations on memory data structures
US11442858B1 (en) * 2021-03-10 2022-09-13 Micron Technology, Inc. Bias control for a memory device
CN113114733B (zh) * 2021-03-24 2022-07-08 重庆邮电大学 基于能量收集的分布式任务卸载和计算资源的管理方法
US11934658B2 (en) 2021-03-25 2024-03-19 Mellanox Technologies, Ltd. Enhanced storage protocol emulation in a peripheral device
US11481343B1 (en) 2021-04-02 2022-10-25 Micron Technology, Inc. Transporting request types with different latencies
CN113191046A (zh) * 2021-04-20 2021-07-30 河海大学 一种基于ras对等式交互的有限元程序并行化方法
CN113076519A (zh) * 2021-04-21 2021-07-06 湖北九同方微电子有限公司 基于arm架构的大型矩阵求解方法
US11693779B2 (en) 2021-04-30 2023-07-04 International Business Machines Corporation Prefetch of random data using application tags
US20220155847A1 (en) * 2021-05-04 2022-05-19 Intel Corporation Technologies for a processor to enter a reduced power state while monitoring multiple addresses
US11782865B1 (en) * 2021-06-02 2023-10-10 Amazon Technologies, Inc. Flexible data handling
CN113238853B (zh) * 2021-06-15 2021-11-12 上海交通大学 基于函数中间表达的无服务器计算调度系统及方法
US12079658B2 (en) 2021-06-17 2024-09-03 International Business Machines Corporation Detection of invalid machine-specific data types during data conversion
US11675592B2 (en) * 2021-06-17 2023-06-13 International Business Machines Corporation Instruction to query for model-dependent information
US11899589B2 (en) 2021-06-22 2024-02-13 Samsung Electronics Co., Ltd. Systems, methods, and devices for bias mode management in memory systems
US11848838B2 (en) * 2021-06-24 2023-12-19 Hewlett Packard Enterprise Development Lp Communicating node events in network configuration
US11853231B2 (en) 2021-06-24 2023-12-26 Ati Technologies Ulc Transmission of address translation type packets
KR102593034B1 (ko) * 2021-07-02 2023-10-23 고려대학교 산학협력단 다차원 데이터베이스를 위한 스토리지내 데이터 재구성 가속기
US20230040226A1 (en) * 2021-07-27 2023-02-09 Intel Corporation Method and apparatus for dynamically adjusting pipeline depth to improve execution latency
WO2023009641A1 (en) * 2021-07-27 2023-02-02 Intel Corporation Data streaming accelerator
US20230042934A1 (en) * 2021-07-27 2023-02-09 Intel Corporation Method and apparatus for high-performance page-fault handling for multi-tenant scalable accelerators
US11537313B1 (en) * 2021-08-11 2022-12-27 EMC IP Holding Company LLC Dual cast mirroring from host devices
US11829627B2 (en) * 2021-08-16 2023-11-28 Micron Technology, Inc. Data migration schedule prediction using machine learning
CN113901492A (zh) * 2021-09-06 2022-01-07 苏州国芯科技股份有限公司 数据传输的加解密方法、装置、系统及设备
CN113742267B (zh) * 2021-09-07 2023-10-27 中国科学院计算技术研究所 一种用于rdma通信设备的dma通信系统及方法
CN113780553B (zh) * 2021-09-09 2023-11-07 中山大学 一种基于高层次综合工具的深度学习模型优化方法及系统
CN113553191B (zh) * 2021-09-17 2022-01-04 深圳致星科技有限公司 用于联邦学习和隐私计算的异构处理系统
CN114048066B (zh) * 2021-10-21 2024-06-04 北京航天晨信科技有限责任公司 一种基于guid识别的板卡深度信息智能管理方法
CN114095958B (zh) * 2021-11-16 2023-09-12 新华三大数据技术有限公司 小区覆盖区域确定方法、装置、设备及存储介质
US20230161725A1 (en) * 2021-11-23 2023-05-25 Meta Platforms, Inc. Smart scalable design for a crossbar
TWI811862B (zh) * 2021-11-24 2023-08-11 宏碁股份有限公司 虛擬環境建立方法與電子裝置
CN118265973A (zh) * 2021-11-25 2024-06-28 华为技术有限公司 一种消息处理方法及装置
CN118369671A (zh) * 2021-12-13 2024-07-19 三菱电机株式会社 信息处理装置、程序和信息处理方法
CN114237712B (zh) * 2021-12-15 2022-12-27 北京百度网讯科技有限公司 指令执行方法、装置、电子设备及计算机存储介质
CN113987589B (zh) * 2021-12-27 2022-03-18 飞天诚信科技股份有限公司 一种处理数据的方法、装置、计算机可读存储介质及装置
CN113992687B (zh) * 2021-12-28 2022-04-08 浙江宇视科技有限公司 智能业务集群调度方法、装置、电子设备及存储介质
US11934310B2 (en) * 2022-01-21 2024-03-19 Centaur Technology, Inc. Zero bits in L3 tags
CN116701292A (zh) 2022-02-24 2023-09-05 平头哥(上海)半导体技术有限公司 用于芯片间通信的处理系统和通信方法
CN114580628A (zh) * 2022-03-14 2022-06-03 北京宏景智驾科技有限公司 一种神经网络卷积层的高效量化加速方法及硬件电路
US11635988B1 (en) 2022-03-15 2023-04-25 Sas Institute Inc. Optimal number of threads determination system
CN114328592B (zh) * 2022-03-16 2022-05-06 北京奥星贝斯科技有限公司 聚合计算方法和装置
US20230305846A1 (en) * 2022-03-24 2023-09-28 Intel Corporation Processor hardware and instructions for vectorized fused and-xor
CN114827048B (zh) * 2022-03-26 2023-10-20 西安电子科技大学 一种动态可配高性能队列调度方法、系统、处理器及协议
US20230367513A1 (en) * 2022-05-13 2023-11-16 Silicon Motion, Inc. Storage device capable of dynamically determining whether to and when to send next interrupt event to host device
WO2023225049A1 (en) * 2022-05-17 2023-11-23 Schlumberger Technology Corporation Integrated customer delivery system
CN116264009B (zh) * 2022-06-21 2023-10-27 中兴通讯股份有限公司 光伏系统的数据处理方法、数据处理终端及存储介质
US20230418767A1 (en) 2022-06-28 2023-12-28 Apple Inc. PC-Based Memory Permissions
CN117348930A (zh) * 2022-06-29 2024-01-05 中科寒武纪科技股份有限公司 指令处理装置、指令执行方法、片上系统和板卡
CN117349223A (zh) * 2022-06-29 2024-01-05 中科寒武纪科技股份有限公司 片上系统、指令系统、编译系统及相关产品
US11930611B2 (en) * 2022-07-29 2024-03-12 Dell Products, L.P. Configurable chassis supporting replaceable hardware accelerator baseboards
CN115017095B (zh) * 2022-08-05 2022-11-08 微传智能科技（常州）有限公司 电流输出型ak协议轮速芯片通信系统及方法
GB2622581A (en) * 2022-09-14 2024-03-27 Advanced Risc Mach Ltd Multiple-outer-product instruction
CN115248701B (zh) * 2022-09-21 2022-12-20 进迭时空(杭州)科技有限公司 一种处理器寄存器堆之间的零拷贝数据传输装置及方法
US12001352B1 (en) 2022-09-30 2024-06-04 Amazon Technologies, Inc. Transaction ordering based on target address
US20240127107A1 (en) * 2022-10-14 2024-04-18 Microsoft Technology Licensing, Llc Program accelerators with multidimensional nested command structures
US20240231910A9 (en) * 2022-10-19 2024-07-11 Mediatek Inc. Optimization of Scratchpad Memory Allocation for Heterogeneous Devices Using A Cooperative Compiler Framework
US12117948B2 (en) 2022-10-31 2024-10-15 Mellanox Technologies, Ltd. Data processing unit with transparent root complex
US20240143295A1 (en) * 2022-11-01 2024-05-02 Advanced Micro Devices, Inc. Software compilation for networked processing system
US12007921B2 (en) 2022-11-02 2024-06-11 Mellanox Technologies, Ltd. Programmable user-defined peripheral-bus device implementation using data-plane accelerator (DPA)
WO2024107364A1 (en) * 2022-11-14 2024-05-23 Ascenium, Inc. Parallel processing using hazard detection and mitigation
CN116257320B (zh) * 2022-12-23 2024-03-08 中科驭数（北京）科技有限公司 一种基于dpu虚拟化配置管理方法、装置、设备及介质
TWI826216B (zh) * 2022-12-29 2023-12-11 瑞昱半導體股份有限公司 記憶體控制系統與記憶體控制方法
WO2024145021A1 (en) * 2022-12-30 2024-07-04 Advanced Neuromodulation Systems, Inc. Implantable medical device (imd) with code path metrics
US20240256285A1 (en) * 2023-01-31 2024-08-01 Microsoft Technology Licensing, Llc Parallelizing multi-phase kernels with cross-phase dependency on heterogenous hardware
CN115951841B (zh) * 2023-02-27 2023-06-20 浪潮电子信息产业股份有限公司 存储系统及创建方法、数据处理方法、装置、设备和介质
KR20240137221A (ko) * 2023-03-08 2024-09-20 에스케이하이닉스 주식회사 사전리드동작을 위해 할당된 캐시 크기를 조절하는 장치 및 방법
CN115952385B (zh) * 2023-03-10 2023-05-05 山东省计算中心（国家超级计算济南中心） 用于大规模稀疏方程组求解的并行超节点排序方法及系统
WO2024189796A1 (ja) * 2023-03-14 2024-09-19 日本電信電話株式会社 タスクスケジューラ装置、タスクスケジューリング方法およびプログラム
CN115982091B (zh) * 2023-03-21 2023-06-23 深圳云豹智能有限公司 基于rdma引擎的数据处理方法与系统、介质、设备
CN116149759B (zh) * 2023-04-20 2023-07-14 深圳市吉方工控有限公司 Uefi驱动卸载方法、装置、电子设备及可读存储介质
CN116700731B (zh) * 2023-05-12 2024-09-24 珠海市芯动力科技有限公司 代码编译方法及相关装置
TWI838264B (zh) * 2023-06-01 2024-04-01 和碩聯合科技股份有限公司 電腦系統及其電腦系統除錯資訊處理之方法
CN116821174B (zh) * 2023-07-17 2024-07-19 深圳计算科学研究院 一种基于逻辑数据块的数据查询方法及其装置
CN116627893B (zh) * 2023-07-18 2023-11-03 苏州浪潮智能科技有限公司 加速引擎配置方法、装置、并行数估计系统、设备及介质
CN117112596A (zh) * 2023-07-28 2023-11-24 中科驭数（北京）科技有限公司 数据处理方法、装置、设备及计算机可读存储介质
CN116700631B (zh) * 2023-08-03 2023-09-29 摩尔线程智能科技(北京)有限责任公司 任务管理装置、方法、图形处理器及电子设备
CN117331720B (zh) * 2023-11-08 2024-02-23 瀚博半导体(上海)有限公司 用于多核间通信的方法、寄存器组、芯片及计算机设备
CN117749718B (zh) * 2023-12-07 2024-07-16 无锡众星微系统技术有限公司 基于ack和nop机制的dma传输保序处理方法和装置
CN117389625B (zh) * 2023-12-11 2024-03-12 沐曦集成电路(南京)有限公司 基于主动中断指令的进程同步方法、系统、设备及介质
CN117389693B (zh) * 2023-12-12 2024-04-05 麒麟软件有限公司 一种硬件虚拟化系统io层安全检测方法
CN117521061B (zh) * 2024-01-05 2024-03-15 南京南自华盾数字技术有限公司 一种基于二进制转换器的定时旁路攻击安全防护方法
CN118113631B (zh) * 2024-04-30 2024-07-02 山东海量信息技术研究院 一种数据处理系统、方法、设备、介质及计算机程序产品
CN118294990B (zh) * 2024-06-05 2024-08-06 杭州芯云半导体技术有限公司 一种用于导航芯片的测试系统及测试方法

Family Cites Families (69)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6839728B2 (en) 1998-10-09 2005-01-04 Pts Corporation Efficient complex multiplication and fast fourier transform (FFT) implementation on the manarray architecture
WO2001016703A1 (en) 1999-09-01 2001-03-08 Intel Corporation Instruction for multithreaded parallel processor
EP1236097A4 (en) 1999-09-01 2006-08-02 Intel Corp BRANCH COMMAND TO THE PROCESSOR
US6738831B2 (en) * 2001-12-12 2004-05-18 Intel Corporation Command ordering
US20030120878A1 (en) 2001-12-21 2003-06-26 Andreassen Jens Kloster Resource sharing using a locking mechanism in a multiprocessor environment
US6697076B1 (en) * 2001-12-31 2004-02-24 Apple Computer, Inc. Method and apparatus for address re-mapping
US7068072B2 (en) * 2003-06-30 2006-06-27 Xilinx, Inc. Integrated circuit with interface tile for coupling to a stacked-die second integrated circuit
US7754539B2 (en) * 2003-10-08 2010-07-13 Sige Semiconductor Inc. Module integration integrated circuits
US7765543B1 (en) * 2003-12-17 2010-07-27 Vmware, Inc. Selective descheduling of idling guests running on a host computer system
US7109734B2 (en) * 2003-12-18 2006-09-19 Xilinx, Inc. Characterizing circuit performance by separating device and interconnect impact on signal delay
US7450959B2 (en) * 2003-12-31 2008-11-11 Qualcomm Incorporated Wireless multiprocessor system-on-chip with unified memory and fault inhibitor
US7366865B2 (en) * 2004-09-08 2008-04-29 Intel Corporation Enqueueing entries in a packet queue referencing packets
CN100531394C (zh) * 2004-12-30 2009-08-19 美国博通公司 微处理器中视频运动处理的方法和系统
US7447873B1 (en) * 2005-11-29 2008-11-04 Nvidia Corporation Multithreaded SIMD parallel processor with loading of groups of threads
US20070271325A1 (en) 2006-05-08 2007-11-22 Nvidia Corporation Matrix multiply with reduced bandwidth requirements
JP4784827B2 (ja) * 2006-06-06 2011-10-05 学校法人早稲田大学 ヘテロジニアスマルチプロセッサ向けグローバルコンパイラ
US8345053B2 (en) 2006-09-21 2013-01-01 Qualcomm Incorporated Graphics processors with parallel scheduling and execution of threads
US8860741B1 (en) * 2006-12-08 2014-10-14 Nvidia Corporation Graphics processor with memory management unit and cache coherent link
CN101308461A (zh) 2007-05-18 2008-11-19 国际商业机器公司 处理器及其中处理锁事务的方法
US7783822B2 (en) * 2007-07-25 2010-08-24 Hewlett-Packard Development Company, L.P. Systems and methods for improving performance of a routable fabric
US8347005B2 (en) * 2007-07-31 2013-01-01 Hewlett-Packard Development Company, L.P. Memory controller with multi-protocol interface
US7921272B2 (en) 2007-10-05 2011-04-05 International Business Machines Corporation Monitoring patterns of processes accessing addresses in a storage device to determine access parameters to apply
US8055856B2 (en) 2008-03-24 2011-11-08 Nvidia Corporation Lock mechanism to enable atomic updates to shared memory
US7827336B2 (en) 2008-11-10 2010-11-02 Freescale Semiconductor, Inc. Technique for interconnecting integrated circuits
US8115511B2 (en) * 2009-04-14 2012-02-14 Monolithic 3D Inc. Method for fabrication of a semiconductor device and structure
US8843682B2 (en) 2010-05-18 2014-09-23 Lsi Corporation Hybrid address mutex mechanism for memory accesses in a network processor
JP5720577B2 (ja) 2009-12-04 2015-05-20 日本電気株式会社 サーバ及びフロー制御プログラム
US9268611B2 (en) 2010-09-25 2016-02-23 Intel Corporation Application scheduling in heterogeneous multiprocessor computing platform based on a ratio of predicted performance of processor cores
JP2012073741A (ja) * 2010-09-28 2012-04-12 Fuji Electric Co Ltd バス転送システム
US9019791B2 (en) * 2010-11-03 2015-04-28 Shine C. Chung Low-pin-count non-volatile memory interface for 3D IC
US8683243B2 (en) * 2011-03-11 2014-03-25 Intel Corporation Dynamic core selection for heterogeneous multi-core systems
US9330430B2 (en) * 2011-03-21 2016-05-03 Apple Inc. Fast queries in a multithreaded queue of a graphics system
EP2689327B1 (en) 2011-03-25 2021-07-28 Intel Corporation Executing instruction sequence code blocks by using virtual cores instantiated by partitionable engines
US8935683B2 (en) * 2011-04-20 2015-01-13 Qualcomm Incorporated Inline function linking
US9846673B2 (en) * 2011-11-04 2017-12-19 Waseda University Processor, accelerator, and direct memory access controller within a processor core that each reads/writes a local synchronization flag area for parallel execution
US8707314B2 (en) * 2011-12-16 2014-04-22 Advanced Micro Devices, Inc. Scheduling compute kernel workgroups to heterogeneous processors based on historical processor execution times and utilizations
US9436512B2 (en) * 2011-12-22 2016-09-06 Board Of Supervisors Of Louisana State University And Agricultural And Mechanical College Energy efficient job scheduling in heterogeneous chip multiprocessors based on dynamic program behavior using prim model
CN103999162A (zh) 2011-12-23 2014-08-20 英特尔公司 用于堆叠存储器架构的自修复逻辑
WO2013101139A1 (en) * 2011-12-30 2013-07-04 Intel Corporation Providing an asymmetric multicore processor system transparently to an operating system
EP2842031A4 (en) * 2012-04-25 2015-12-30 Intel Corp METHOD AND SYSTEM FOR SAVING THE RELEASE CONSISTENCY IN A COMMON MEMORY PROGRAMMING
WO2013177765A1 (en) * 2012-05-30 2013-12-05 Intel Corporation Runtime dispatching among heterogeneous group of processors
US9065722B2 (en) 2012-12-23 2015-06-23 Advanced Micro Devices, Inc. Die-stacked device with partitioned multi-hop network
US8931108B2 (en) 2013-02-18 2015-01-06 Qualcomm Incorporated Hardware enforced content protection for graphics processing units
US9298658B2 (en) 2013-02-26 2016-03-29 Avago Technologies General Ip (Singapore) Pte. Ltd. Using PCI-E extended configuration space to send IOCTLS to a PCI-E adapter
KR101400577B1 (ko) * 2013-03-11 2014-06-19 한양대학교 산학협력단 Gpu를 이용한 희소행렬 곱셈 방법
US9495154B2 (en) * 2013-03-13 2016-11-15 Qualcomm Incorporated Vector processing engines having programmable data path configurations for providing multi-mode vector processing, and related vector processors, systems, and methods
US9679615B2 (en) 2013-03-15 2017-06-13 Micron Technology, Inc. Flexible memory system with a controller and a stack of memory
US9525586B2 (en) * 2013-03-15 2016-12-20 Intel Corporation QoS based binary translation and application streaming
JP2014186618A (ja) 2013-03-25 2014-10-02 Toshiba Corp ロックトランザクションコントローラを備えた共有メモリ制御ユニット
US9170854B2 (en) * 2013-06-04 2015-10-27 Advanced Micro Devices, Inc. Thread assignment for power and performance efficiency using multiple power states
US20150007196A1 (en) * 2013-06-28 2015-01-01 Intel Corporation Processors having heterogeneous cores with different instructions and/or architecural features that are presented to software as homogeneous virtual cores
US9571363B2 (en) * 2013-07-15 2017-02-14 Centurylink Intellectual Property Llc Control groups for network testing
US9507404B2 (en) 2013-08-28 2016-11-29 Via Technologies, Inc. Single core wakeup multi-core synchronization mechanism
US20150109024A1 (en) 2013-10-22 2015-04-23 Vaughn Timothy Betz Field Programmable Gate-Array with Embedded Network-on-Chip Hardware and Design Flow
US10915468B2 (en) * 2013-12-26 2021-02-09 Intel Corporation Sharing memory and I/O services between nodes
CN105765544B (zh) 2013-12-26 2019-04-09 英特尔公司 多芯片封装链路
US10031773B2 (en) * 2014-02-20 2018-07-24 Nxp Usa, Inc. Method to communicate task context information and device therefor
US9519324B2 (en) * 2014-03-26 2016-12-13 Intel Corporation Local power gate (LPG) interfaces for power-aware operations
US9703948B2 (en) * 2014-03-28 2017-07-11 Intel Corporation Return-target restrictive return from procedure instructions, processors, methods, and systems
WO2015150342A1 (en) * 2014-03-30 2015-10-08 Universiteit Gent Program execution on heterogeneous platform
US20160111406A1 (en) * 2014-10-17 2016-04-21 Globalfoundries Inc. Top-side interconnection substrate for die-to-die interconnection
US10417052B2 (en) * 2014-10-31 2019-09-17 Hewlett Packard Enterprise Development Lp Integrated heterogeneous processing units
US9921768B2 (en) * 2014-12-18 2018-03-20 Intel Corporation Low power entry in a shared memory link
US20160191420A1 (en) * 2014-12-27 2016-06-30 Intel Corporation Mitigating traffic steering inefficiencies in distributed uncore fabric
US10229468B2 (en) * 2015-06-03 2019-03-12 Intel Corporation Automated conversion of GPGPU workloads to 3D pipeline workloads
US9870339B2 (en) 2015-06-26 2018-01-16 Intel Corporation Hardware processors and methods for tightly-coupled heterogeneous computing
US9703603B1 (en) * 2016-04-25 2017-07-11 Nxp Usa, Inc. System and method for executing accelerator call
US10042673B1 (en) * 2016-05-02 2018-08-07 EMC IP Holdings Company LLC Enhanced application request based scheduling on heterogeneous elements of information technology infrastructure
US9761564B1 (en) 2016-06-30 2017-09-12 Micron Technology, Inc. Layout of transmission vias for memory device

Also Published As

Publication number Publication date
CN116755778A (zh) 2023-09-15
TW202240387A (zh) 2022-10-16
TW202347124A (zh) 2023-12-01
TWI742964B (zh) 2021-10-11
US11416281B2 (en) 2022-08-16
CN115454586A (zh) 2022-12-09
TW202121169A (zh) 2021-06-01
BR112019010679A2 (pt) 2019-09-17
EP3563235B1 (en) 2022-10-05
US20200401440A1 (en) 2020-12-24
EP4120070A1 (en) 2023-01-18
KR20200140395A (ko) 2020-12-15
KR20220090588A (ko) 2022-06-29
CN110121698A (zh) 2019-08-13
EP4089531B1 (en) 2024-06-26
JP2020503593A (ja) 2020-01-30
US20220164218A1 (en) 2022-05-26
PL3812900T3 (pl) 2024-04-08
EP4398113A2 (en) 2024-07-10
KR20190093568A (ko) 2019-08-09
EP3563235A1 (en) 2019-11-06
KR102674024B1 (ko) 2024-06-13
TWI832298B (zh) 2024-02-11
EP4089531A1 (en) 2022-11-16
FI3812900T3 (fi) 2024-02-09
EP3812900B1 (en) 2023-11-29
US11093277B2 (en) 2021-08-17
JP6988040B2 (ja) 2022-01-05
KR20230106746A (ko) 2023-07-13
EP4120070B1 (en) 2024-05-01
TW201826122A (zh) 2018-07-16
DK3812900T3 (da) 2024-02-12
KR102520017B1 (ko) 2023-04-11
PL3563235T3 (pl) 2023-03-13
ES2974451T3 (es) 2024-06-27
CN112506568A (zh) 2021-03-16
TWI810166B (zh) 2023-08-01
US11693691B2 (en) 2023-07-04
EP3812900A1 (en) 2021-04-28
US20230418655A1 (en) 2023-12-28
DE112016007566T5 (de) 2019-09-26
US20190347125A1 (en) 2019-11-14
EP3563235A4 (en) 2020-08-26
WO2018125250A1 (en) 2018-07-05

Similar Documents

Publication Publication Date Title
ES2933675T3 (es) Sistemas, métodos y aparatos para informática heterogénea
Pellegrini et al. The arm neoverse n1 platform: Building blocks for the next-gen cloud-to-edge infrastructure soc
US10606750B1 (en) Computing in parallel processing environments
JP7525101B2 (ja) ヘテロジニアスコンピューティングのためのシステム、方法及び装置
Santos et al. Solving datapath issues on near-data accelerators