Intel Patent | Keyboard For Virtual Reality
Patent: Keyboard For Virtual Reality
Publication Number: 10606343
Publication Date: 20200331
Applicants: Intel
Abstract
An embodiment of a graphics apparatus may include an image generator, and a gesture tracker communicatively coupled to the image generator. The image generator may be configured to generate an image of a virtual input device, the gesture tracker may be configured to determine a position of a user’s finger relative to the virtual input device, and the image generator may be further configured to generate an image of a virtual finger based on the determined position of the user’s finger relative to the virtual input device. Other embodiments are disclosed and claimed.
TECHNICAL FIELD
Embodiments generally relate to virtual reality (VR). More particularly, embodiments relate to a keyboard for virtual reality.
BACKGROUND
A VR environment may include a host system running a VR application connected to a head-mounted display (HMD) to immerse a user in a virtual environment. As the user moves or turns their head, the display may be updated to track the motion so the user may perceive what is displayed as appearing to be a realistic environment. In the VR environment, user input may typically take the form of sensed head movement, eye tracking or gesture recognition.
BRIEF DESCRIPTION OF THE DRAWINGS
The various advantages of the embodiments will become apparent to one skilled in the art by reading the following specification and appended claims, and by referencing the following drawings, in which:
FIG. 1 is a block diagram of an example of an electronic processing system according to an embodiment;
FIG. 2 is a block diagram of an example of a graphics apparatus according to an embodiment;
FIGS. 3 to 5 are flowcharts of an example of a method of displaying virtual objects according to an embodiment;
FIGS. 6A to 6B are illustrative diagrams of an example of a user with a VR system according to an embodiment;
FIG. 7 is an illustrative diagram of an example of displayed virtual objects according to an embodiment;
FIGS. 8-10 are block diagrams of an example of an overview of a data processing system according to an embodiment;
FIG. 11 is a block diagram of an example of a graphics processing engine according to an embodiment;
FIGS. 12-14 are block diagrams of examples of execution units according to an embodiment;
FIG. 15 is a block diagram of an example of a graphics pipeline according to an embodiment;
FIGS. 16A-16B are block diagrams of examples of graphics pipeline programming according to an embodiment;
FIG. 17 is a block diagram of an example of a graphics software architecture according to an embodiment;
FIG. 18 is a block diagram of an example of an intellectual property (IP) core development system according to an embodiment;* and*
FIG. 19 is a block diagram of an example of a system on a chip integrated circuit according to an embodiment.
DESCRIPTION OF EMBODIMENTS
Turning now to FIG. 1, an embodiment of an electronic processing system 10 may include an application processor 11, persistent storage media 12 communicatively coupled to the application processor 11, a graphics processor 13 communicatively coupled to the application processor 11, and a gesture tracker 14 communicatively coupled to the application processor 11. In some embodiments, the graphics processor 13 may be configured to generate an image of a virtual input device, the gesture tracker 14 may be configured to determine a position of a user’s finger relative to the virtual input device, and the graphics processor 13 may be further configured to generate an image of a virtual finger based on the determined position of the user’s finger relative to the virtual input device. Some embodiments of the system 10 may further include an input generator 15 communicatively coupled to the gesture tracker 14 to generate input data based on the determined position of the user’s finger relative to the virtual input device. Some embodiments of the system may additionally, or alternatively, include a device tracker 16 communicatively coupled to the graphics processor 13 to identify a characteristic of a physical input device. For example, the graphics processor 13 may be configured to generate the image of the virtual input device based on the identified characteristic of the physical input device.
Embodiments of each of the above application processor 11, persistent storage media 12, graphics processor 13, gesture tracker 14, input generator 15, device tracker 16, and other system components may be implemented in hardware, software, or any suitable combination thereof. For example, hardware implementations may include configurable logic such as, for example, programmable logic arrays (PLAs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), or in fixed-functionality logic hardware using circuit technology such as, for example, ASIC, complementary metal oxide semiconductor (CMOS) or transistor-transistor logic (TTL) technology, or any combination thereof. Alternatively, or additionally, these components may be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium such as random access memory (RAM), read only memory (ROM), programmable ROM (PROM), firmware, flash memory, etc., to be executed by a processor or computing device. For example, computer program code to carry out the operations of the components may be written in any combination of one or more operating system applicable/appropriate programming languages, including an object-oriented programming language such as PYTHON, PERL, JAVA, SMALLTALK, C++, C# or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages.
* Sensor Examples*
For example, a VR system may include a variety of sensors such as two dimensional (2D) cameras, three dimensional (3D) cameras, depth cameras, gyroscopes, accelerometers, inertial measurement units (IMUs), location services, microphones, proximity sensors, thermometers, biometric sensors, etc. The sensors may be distributed across multiple devices. Some embodiments may include an INTEL REALSENSE camera. The information from the sensors may include or be combined with input data from the user’s other devices (e.g. smartphones, wearable devices, human interface devices (HIDs), etc.). For example, the user’s device(s) may include one or more 2D, 3D, and/or depth cameras. The user’s device(s) may also include gyroscopes, accelerometers, IMUs, location services, thermometers, biometric sensors, etc. For example, the user may carry a smartphone (e.g. in the user’s pocket) and/or may wear a wearable device (e.g. such as a smart watch, an activity monitor, and/or a fitness tracker). The user’s device(s) may also include a microphone which may be utilized to detect if the user is speaking, on the phone, speaking to another nearby person, etc.
The sensors available to the VR system may also include some or all of the user’s various other devices which are capable of capturing information related to the user’s actions or activity (e.g. including an input/output (I/O) interface of the user devices which can capture keyboard/mouse/touch activity). The VR system may get information directly from the user’s other devices (e.g. wired or wirelessly) or the VR system may be able to integrate information from the devices from a server or a service (e.g. information may be uploaded from a fitness tracker to a cloud service, which the VR system may download).
* Gesture Tracker Examples*
The VR system may be configured to perform facial recognition, gaze tracking, facial expression recognition, and/or gesture recognition including body-level gestures, arm/leg-level gestures, hand-level gestures, and/or finger-level gestures. For example, a machine vision system may be configured to classify an action of the user. In some embodiments, a suitably configured machine vision system may be able to determine if the user is present at a computer, typing at a keyboard, using a mouse, using a trackpad, using a touchscreen, using a HMD, using a VR system, sitting, standing, and/or otherwise taking some other action or activity. For example, devices such as the MICROSOFT KINECT and the MICROSOFT HOLOLENSE may provide various gesture tracking capabilities.
* Device Tracker Examples*
Some embodiments of a VR system, for example, may analyze and/or perform feature/object recognition on images captured by a camera. For example, machine vision and/or image processing may identify and/or recognize objects in a scene (e.g. a desk, a table, a keyboard, mouse, other HIDs, etc.). For example, the device tracker may get camera data related to a real object in a scene and may use that information to identify position and orientation of the real object. In some embodiments, the device tracker may be configured to construct a 3D model of an object in the captured scene. The device tracker may also identify when the real object in the scene moves from one position/orientation to another.
Focus/Gaze Tracker Examples
The VR system may get information from the sensors to determine focus information. At a high level, focus information may be based on 1) where the user is assumed to be looking, 2) where the user is determined to be looking, 3) where an application wants the user to look, and/or 4) where the user is predicted to be looking in the future. Some focus cues may be stronger in the focal region of where the user is looking. If the user is looking straight ahead they may see things in sharp focus. With scenes or objects towards the periphery, the user may notice motion but not details in sharp focus.
Some embodiments, for example, may include an eye tracker or get eye information from an eye tracker to track the user’s eyes. The user may go through a calibration process which may help the eye tracker provide more accurate information. When a user is wearing a VR headset, for example, a camera may capture an image of a pupil and the system may determine where the user is looking (e.g. a focus area, depth of field, and/or direction). The camera may capture pupil information and the system may infer where the user’s focus area is based on that information.
* Motion Tracker Examples*
The VR system may also get information from the sensors, and/or the focus/gaze tracker, and other sources to provide motion information. At a high level, motion information may be based on 1) the user moving their head, 2) the user moving their eyes, 3) the user moving their body, 4) where an application wants the user to turn their head, eyes, and/or body, and/or 4) where the user is predicted to turn their head, eyes, and/or body in the future. Some motion information may be determined readily from the sensed information. For example, head position, velocity, acceleration, motion direction, etc. may be determined from an accelerometer. Eye motion information may be determined by tracking eye position information over time (e.g. if the eye tracker provides only eye position information).
Some motion information may be content-based. In a game or on-the-fly 3D content, for example, the application may know how quickly and where the objects are moving. The application may provide the information to the motion tracker (e.g. through an application programming interface (API) call). Future content-based object motion information for a next frame/scene may also be fed into the motion tracker for decision making. Some content-based motion information may be determined by image processing or machine vision processing the content.
* Tracker Overlap Examples*
Those skilled in the art will appreciate that aspects of various trackers described herein may overlap with other trackers and that portions of each tracker may be implemented or distributed throughout various portions of an electronic processing system. For example, the focus tracker may use motion information to provide a predicted future focus area and the motion tracker may use focus information to predict a future motion. Eye motion information may come directly from an eye tracker, may be determined/predicted by the focus tracker, and/or may be determined/predicted by the motion tracker. The examples herein should be considered as illustrative and not limiting in terms of specific implementations.
Turning now to FIG. 2, an embodiment of a graphics apparatus 20 may include an image generator 21, and a gesture tracker 22 communicatively coupled to the image generator 21. In some embodiments, the image generator 21 may be configured to generate an image of a virtual input device, the gesture tracker 22 may be configured to determine a position of a user’s finger relative to the virtual input device, and the image generator 21 may also be configured to generate an image of a virtual finger based on the determined position of the user’s finger relative to the virtual input device. The gesture tracker 22 may be further configured to determine a position of a user’s hand relative to the virtual input device, and the image generator may be further configured to generate an image of a virtual hand based on the determined position of the user’s hand relative to the virtual input device.
In some embodiments, the apparatus 20 may further include an input generator 23 communicatively coupled to the gesture tracker 22 to generate input data based on the determined position of the user’s finger relative to the virtual input device. For example, the image generator 21 may generate a visual indication corresponding to the generated input data. For example, if the user presses a key in the real or virtual environments, the key may appear to move or may appear immersed as if it was pressed in the virtual environment. Additionally, or alternatively, the key may be highlighted with a different color, the key may be outlined, or some other visual indication may be generated. In addition, or alternatively, audio, haptic, or other feedback may be generated corresponding to the generated input data (e.g. a key click sound).
Some embodiments may additionally, or alternatively include a device tracker 24 communicatively coupled to the image generator 21 to identify a characteristic of a physical input device, where the image generator 21 may be further configured to generate the image of the virtual input device based on the identified characteristic of the physical input device. For example, the device tracker 24 may be configured to determine a position of the physical input device relative to the user, and the gesture tracker 22 may be configured to determine a position the user’s hand relative to the position of the physical input device. The image generator may be configured to generate an image of a virtual representation of the physical input device based on the position of the physical input device relative to the user, and to generate an image of a virtual hand based on the determined position of the user’s hand relative to the physical input device. In some embodiments, the image generator 21 may be configured to load a three-dimensional model of the virtual input device based on the identified characteristic of the physical input device. In any of the embodiments herein, non-limiting examples of the virtual input device may include any of a virtual keyboard, a virtual mouse, a virtual touchpad, a virtual stylus, and a virtual scroll wheel.
For example, embodiments or portions of the image generator 21 may be implemented in applications or driver software (e.g. through an API). Other embodiments or portions of the image generator 21 may be implemented in specialized code (e.g. shaders) to be executed on a graphics processor unit (GPU). Other embodiments or portions of the image generator 21 may be implemented in fixed function logic or specialized hardware (e.g. in the GPU). In some embodiments, the image generator 21 may be part of a VR application with access to a database/library of 3D models of input devices and a database/library of 3D models of fingers and/or hands. For example, the VR application may run on a general purpose processor which calls appropriate driver routines and/or graphics routines to generate images of the virtual input device(s), virtual finger(s), and/or virtual hands on the display(s). In some embodiments, the image generator 21 may be part of a VR runtime system loaded as driver routines. For example, VR applications may simply request input through an API call and the VR runtime routines may execute appropriate code and call appropriate graphics routines to generate the images of the virtual input device(s), virtual finger(s), and/or virtual hands on the display(s).
For example, embodiments or portions of the input generator 23 may be implemented in applications or driver software (e.g. through an API). Other embodiments or portions of the input generator 23 may be implemented in specialized code (e.g. shaders) to be executed on a GPU. Other embodiments or portions of the input generator 23 may be implemented in fixed function logic or specialized hardware (e.g. in the GPU). For example, the input generator 23 may get information from a gesture tracker to indicate that the user has performed a key press action with a particular finger. The input generator 23 may determine the position of the corresponding virtual finger relative to the virtual keyboard to identify which key the user pressed (or virtually pressed). The input generator 23 may then send a signal through the IO interface corresponding to the identified key. The input generator 23 may also be configured to generate signals through the IO interface that correspond to gestures such as touch (e.g. for a touchpad or a touch screen), scrolling (e.g. for a scroll wheel on a mouse), button clicks (e.g. for mouse buttons). The input generator 23 may also be configured to generate signals through the IO interface based on information from the gesture tracker 22 and/or the device tracker 24 that correspond to movement of an input device (e.g. such as moving a physical mouse or virtually moving a virtual mouse).
Embodiments of each of the above image generator 21, gesture tracker 22, input generator 23, device tracker 24, and other components of the apparatus 20 may be implemented in hardware, software, or any combination thereof. For example, hardware implementations may include configurable logic such as, for example, PLAs, FPGAs, CPLDs, or in fixed-functionality logic hardware using circuit technology such as, for example, ASIC, CMOS, or TTL technology, or any combination thereof. Alternatively, or additionally, these components may be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium such as RAM, ROM, PROM, firmware, flash memory, etc., to be executed by a processor or computing device. For example, computer program code to carry out the operations of the components may be written in any combination of one or more operating system applicable/appropriate programming languages, including an object-oriented programming language such as PYTHON, PERL, JAVA, SMALLTALK, C++, C# or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages.
Turning now to FIGS. 3 to 5, an embodiment of a method 30 of displaying virtual objects may include generating an image of a virtual input device at block 31, determining a position of a user’s finger relative to the virtual input device at block 32, and generating an image of a virtual finger based on the determined position of the user’s finger relative to the virtual input device at block 33. The method 30 may also include determining a position of a user’s hand relative to the virtual input device at block 34, and generating an image of a virtual hand based on the determined position of the user’s hand relative to the virtual input device at block 35. For example, some embodiments may include generating input data based on the determined position of the user’s finger relative to the virtual input device at block 36, and generating a visual indication corresponding to the generated input data at block 37.
In some embodiments, the method 30 may further include identifying a characteristic of a physical input device at block 38, and generating the image of the virtual input device based on the identified characteristic of the physical input device at block 39. For example, the method 30 may include determining a position of the physical input device relative to the user at block 40, determining a position the user’s hand relative to the position of the physical input device at block 41, generating an image of a virtual representation of the physical input device based on the position of the physical input device relative to the user at block 42, and generating an image of a virtual hand based on the determined position of the user’s hand relative to the physical input device at block 43. Some embodiments may further include loading a three-dimensional model of the virtual input device based on the identified characteristic of the physical input device at block 44. For example, the virtual input device may include one of a virtual keyboard, a virtual mouse, a virtual touchpad, a virtual stylus, and a virtual scroll wheel at block 45, among other HIDs.
Embodiments of the method 30 may be implemented in a system, apparatus, application processor, graphics processor unit (GPU), parallel processor unit (PPU), or a graphics processor pipeline apparatus such as, for example, those described herein. More particularly, hardware implementations of the method 30 may include configurable logic such as, for example, PLAs, FPGAs, CPLDs, or in fixed-functionality logic hardware using circuit technology such as, for example, ASIC, CMOS, or TTL technology, or any combination thereof. Alternatively, or additionally, the method 30 may be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium such as RAM, ROM, PROM, firmware, flash memory, etc., to be executed by a processor or computing device. For example, computer program code to carry out the operations of the components may be written in any combination of one or more operating system applicable/appropriate programming languages, including an object-oriented programming language such as PYTHON, PERL, JAVA, SMALLTALK, C++, C# or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. For example, the method 30 may be implemented on a computer readable medium as described in connection with Examples 19 to 25 below.
For example, embodiments or portions of the method 30 may be implemented in applications or driver software (e.g. through an API). Other embodiments or portions of the method 30 may be implemented in specialized code (e.g. shaders) to be executed on a GPU. Other embodiments or portions of the method 30 may be implemented in fixed function logic or specialized hardware (e.g. in the GPU).
While VR applications may be well suited for entertainment, conventional VR systems may not be as well suited for productivity usages such as web browsing, checking e-mail, word processing, spreadsheets, etc. Some embodiments may increase the potential for VR systems to support productivity usages. For example, an embodiment of VR system may replace a multi-monitor desktop setup in a work cubicle with a headset and some wireless input devices, thereby reducing wiring and desktop clutter. Some embodiments may provide a way to use common HIDs, such as keyboard and mouse, which may be important for user productivity. For productivity, a user may want to use their most comfortable HID (such as an ergonomic keyboard/mouse) for long time periods, the same way they might without a HMD. Also, a user who prefers to look at a keyboard while typing may have difficulty typing while wearing the HMD (e.g. without being able to see the keyboard). Some embodiments may advantageously improve usability of a keyboard and/or mouse in a VR environment for productivity usages. For example, some embodiments may expand the use of input devices for VR applications.
For entertainment usages with limited input requirements, some applications or a VR runtime routine may draw a software keyboard, which a user may control through gaze together with a touchpad or controller to enter data. For cursor input, gaze may control a cursor movement and the touchpad/controller may act as a selection action. Gaze control for input may be a limited option for productivity usage. Advantageously, some embodiments may provide better input speed for more intensive data input applications. Some embodiments may also provide more ergonomic comfort for entering data over a longer time period.
Turning now to FIG. 6A, FIG. 6B, and FIG. 7, a VR system 60 may include a HMD 61 to be worn by a user 62. A look-down camera 63 may be positioned on the HMD 61 to capture image and/or depth image information (e.g. see FIG. 6A), which may be used for gesture tracking of the fingers and/or hands 64 of the user 62. If the user 62 addresses a keyboard 65 in the real environment by placing their hands 64 near the keyboard 65 (e.g. see FIG. 6B), a gesture tracker may recognize that gesture and the VR system 60 may generate an image of a virtual keyboard 65v along with virtual hands 64v in the virtual environment shown on a display 66 of the HMD 61 in response to the recognized gesture. The VR system may further recognize a physical mouse 67 in the real environment and generate an image of a virtual mouse 67v in the virtual environment on the display 66. In some embodiments, the VR system 60 may overlay one or more productivity applications 68 (e.g. a file browser, a web browser, and email application, etc.) in front of the VR scene so the user can productively work on another application without removing the HMD 61. As illustrated in FIG. 7, a key press in the real environment may generate a visual indication of a key press 69 in the virtual environment (e.g. a movement of the pressed key in the 3D model, and/or a change in color or highlight of the pressed key).
Some embodiments may provide a VR runtime routine to render a 3D representation of the actual keyboard/mouse model that a user has setup (e.g. or which has been auto-detected). The virtual keyboard may be drawn in the virtual space close to where the user’s finger would be if they were inside the virtual space. Virtual hands/fingers may also be rendered graphically, positioned appropriately on the keys/mouse the user wants to interact with. Some embodiments may texture the animated hands/fingers to match the user’s skin tone/color based on corresponding information sensed by the HMD’s various trackers.
In some embodiments, the VR system may identify a physical input device. For example, the VR runtime routine may present a menu to the user on a one-time basis (which can be overridden or changed), and the user may select the appropriate device (e.g. identified by model numbers of the devices). The user may also attach their physical devices to the VR system and the model or serial number may be auto-detected. For example, if the device is paired over Bluetooth to the VR runtime routine, the model of the device may be identified using the idVendor and idProduct fields of the USB HID Device Descriptor. The VR system may load a 3D model of the identified product either from the cloud or from local storage based on the model or serial number. In some embodiments, the VR system may be able to determine a physical layout of the identified product and generate the 3D model based on the physical layout.
Some embodiments may provide the user two or more options to interact with a physical input device in the virtual environment. For example, the user may connect their physical input device to the VR system and use the device as they normally would for input. Additionally, or alternatively, the user may use a dummy physical device (e.g. not connected to the VR system but still providing haptic feedback through the feel of the device). Additionally, or alternatively, the user may just make the motions of using an input device (e.g. type on the desk or in the air as though a keyboard existed at their hand position). In any of these examples, the user would see a virtual input device in the virtual environment, and a gesture tracker (e.g. a wide angled, world-facing camera on the HMD) may constantly track the user’s hand and finger movements. The VR system may update the rendered image to correspond to the user using the virtual input device. For example, if the user’s finger moves from key “A” to key “L” in the real environment, animated fingers in the virtual space may be updated accordingly. If the user physically repositions the input device (e.g. to get more ergonomic comfort), the location and orientation of the 3D model of that device may be adjusted in the virtual world.
Some embodiments may also be useful for AR/MR applications. For example, if the user does not have physical access to their input device(s), they may make a gesture that the AR/MR system may recognize as addressing a keyboard/mouse/stylus/etc. (e.g. holding both hands out in front of their body with their fingers curved). The AR/MR system may then generate an image of a virtual input device proximate to the user’s hands/fingers for the user to interact with in the AR/MR environment. Advantageously, the virtual input device may correspond to the user’s usual physical input device and the user’s muscle memory for that device may provide more productive use of the virtual input device. In some embodiments, the VR/AR/MR system may scale a size of the virtual keyboard to a detected and/or measured hand size based on the user’s resting and/or natural hand position (e.g. when no physical device is present).
In some embodiments, the user may advantageously have the flexibility to switch seamlessly between their real devices and a pretend device if they don’t have access to their real ones. In some embodiments, the devices may be drawn in the virtual space to closely match a user’s physical setup (e.g. matching a model of a real device, positioned close to the user’s view, texturing the graphical hands with the user’s skin color etc.). The user may advantageously find the setup in the virtual environment very close to the productivity setup they are used to in their real space.
In some embodiments, the user may call up a virtual productivity environment on the HMD display. When the productivity environment is setup, models for virtual input devices may be identified. For example, the user may connect or pair a physical input device (e.g. keyboard/mouse/stylus/touchpad/etc.) to the VR system over a medium such as USB or Bluetooth. The connection may cause exchange of HID descriptors, which may allow the VR system to identify the make and model of the device. The user may additionally, or alternatively, select a device from an appropriate interface. For example, the VR system presents an interface that allows the choice of make and model of their preferred input device. In both (a) and (b), the VR system remembers the choice until overridden with a different preference. In addition, or alternatively, the VR system may read a bar code, a quick-response (QR) code, radio-frequency identification (RFID) tag, or other symbol or tag on the physical input device to recognize the device. In addition, or alternatively, the VR system may use machine vision to recognize the device. In some embodiments, the VR system may be further configured to create a 3D model of the physical input device (e.g. using machine vision).
The VR system may then load a 3D graphical model of the make and model identified (or the created 3D model), either from cloud or local storage (e.g. from a database of 3D models). A world-facing, wide-angled camera on the periphery of the HMD may start tracking the user’s hand, fingers, and any real input device that the user may be interacting with. The VR system may take inputs from the tracker and overlay a graphical version of the user’s hands and input devices, in the orientation and position close to the real scenario (e.g. as detected by the tracking camera). The tracker input may be constantly monitored to update the graphical model with user’s current hand/finger positions. Advantageously, the user may be able to type more comfortably without looking outside the HMD because the user may be able to see their virtual fingers as they type.
In some embodiments, the VR system may be part of a virtual operating system (OS) specifically designed to support VR applications together with productivity applications. When the user brings up the virtual productivity environment, they may pause a VR application to attend to other applications (e.g. e-mail). The paused VR scene may become a background image for the other application windows. For example, the user making a keyboard gesture may automatically pause the current VR application. The user may also allow the VR application to keep running and the virtual OS and/or other application windows may appear to float in front of the VR graphics.
* System Overview*
FIG. 8 is a block diagram of a processing system 100, according to an embodiment. In various embodiments the system 100 includes one or more processors 102 and one or more graphics processors 108, and may be a single processor desktop system, a multiprocessor workstation system, or a server system having a large number of processors 102 or processor cores 107. In on embodiment, the system 100 is a processing platform incorporated within a system-on-a-chip (SoC) integrated circuit for use in mobile, handheld, or embedded devices.
An embodiment of system 100 can include, or be incorporated within a server-based gaming platform, a game console, including a game and media console, a mobile gaming console, a handheld game console, or an online game console. In some embodiments system 100 is a mobile phone, smart phone, tablet computing device or mobile Internet device. Data processing system 100 can also include, couple with, or be integrated within a wearable device, such as a smart watch wearable device, smart eyewear device, augmented reality device, or virtual reality device. In some embodiments, data processing system 100 is a television or set top box device having one or more processors 102 and a graphical interface generated by one or more graphics processors 108.
In some embodiments, the one or more processors 102 each include one or more processor cores 107 to process instructions which, when executed, perform operations for system and user software. In some embodiments, each of the one or more processor cores 107 is configured to process a specific instruction set 109. In some embodiments, instruction set 109 may facilitate Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC), or computing via a Very Long Instruction Word (VLIW). Multiple processor cores 107 may each process a different instruction set 109, which may include instructions to facilitate the emulation of other instruction sets. Processor core 107 may also include other processing devices, such a Digital Signal Processor (DSP).
In some embodiments, the processor 102 includes cache memory 104. Depending on the architecture, the processor 102 can have a single internal cache or multiple levels of internal cache. In some embodiments, the cache memory is shared among various components of the processor 102. In some embodiments, the processor 102 also uses an external cache (e.g., a Level-3 (L3) cache or LLC) (not shown), which may be shared among processor cores 107 using known cache coherency techniques. A register file 106 is additionally included in processor 102 which may include different types of registers for storing different types of data (e.g., integer registers, floating point registers, status registers, and an instruction pointer register). Some registers may be general-purpose registers, while other registers may be specific to the design of the processor 102.
In some embodiments, processor 102 is coupled to a processor bus 110 to transmit communication signals such as address, data, or control signals between processor 102 and other components in system 100. In one embodiment the system 100 uses an exemplary hub system architecture, including a memory controller hub 116 and an Input Output (I/O) controller hub 130. A memory controller hub 116 facilitates communication between a memory device and other components of system 100, while an I/O Controller Hub (ICH) 130 provides connections to I/O devices via a local I/O bus. In one embodiment, the logic of the memory controller hub 116 is integrated within the processor.
Memory device 120 can be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory device, phase-change memory device, or some other memory device having suitable performance to serve as process memory. In one embodiment the memory device 120 can operate as system memory for the system 100, to store data 122 and instructions 121 for use when the one or more processors 102 executes an application or process. Memory controller hub 116 also couples with an optional external graphics processor 112, which may communicate with the one or more graphics processors 108 in processors 102 to perform graphics and media operations.
In some embodiments, ICH 130 enables peripherals to connect to memory device 120 and processor 102 via a high-speed I/O bus. The I/O peripherals include, but are not limited to, an audio controller 146, a firmware interface 128, a wireless transceiver 126 (e.g., Wi-Fi, Bluetooth), a data storage device 124 (e.g., hard disk drive, flash memory, etc.), and a legacy I/O controller 140 for coupling legacy (e.g., Personal System 2 (PS/2)) devices to the system. One or more Universal Serial Bus (USB) controllers 142 connect input devices, such as keyboard and mouse 144 combinations. A network controller 134 may also couple to ICH 130. In some embodiments, a high-performance network controller (not shown) couples to processor bus 110. It will be appreciated that the system 100 shown is exemplary and not limiting, as other types of data processing systems that are differently configured may also be used. For example, the I/O controller hub 130 may be integrated within the one or more processor 102, or the memory controller hub 116 and I/O controller hub 130 may be integrated into a discreet external graphics processor, such as the external graphics processor 112.
FIG. 9 is a block diagram of an embodiment of a processor 200 having one or more processor cores 202A-202N, an integrated memory controller 214, and an integrated graphics processor 208. Those elements of FIG. 9 having the same reference numbers (or names) as the elements of any other figure herein can operate or function in any manner similar to that described elsewhere herein, but are not limited to such. Processor 200 can include additional cores up to and including additional core 202N represented by the dashed lined boxes. Each of processor cores 202A-202N includes one or more internal cache units 204A-204N. In some embodiments each processor core also has access to one or more shared cached units 206.
The internal cache units 204A-204N and shared cache units 206 represent a cache memory hierarchy within the processor 200. The cache memory hierarchy may include at least one level of instruction and data cache within each processor core and one or more levels of shared mid-level cache, such as a Level 2 (L2), Level 3 (L3), Level 4 (L4), or other levels of cache, where the highest level of cache before external memory is classified as the LLC. In some embodiments, cache coherency logic maintains coherency between the various cache units 206 and 204A-204N.
In some embodiments, processor 200 may also include a set of one or more bus controller units 216 and a system agent core 210. The one or more bus controller units 216 manage a set of peripheral buses, such as one or more Peripheral Component Interconnect buses (e.g., PCI, PCI Express). System agent core 210 provides management functionality for the various processor components. In some embodiments, system agent core 210 includes one or more integrated memory controllers 214 to manage access to various external memory devices (not shown).
In some embodiments, one or more of the processor cores 202A-202N include support for simultaneous multi-threading. In such embodiment, the system agent core 210 includes components for coordinating and operating cores 202A-202N during multi-threaded processing. System agent core 210 may additionally include a power control unit (PCU), which includes logic and components to regulate the power state of processor cores 202A-202N and graphics processor 208.
In some embodiments, processor 200 additionally includes graphics processor 208 to execute graphics processing operations. In some embodiments, the graphics processor 208 couples with the set of shared cache units 206, and the system agent core 210, including the one or more integrated memory controllers 214. In some embodiments, a display controller 211 is coupled with the graphics processor 208 to drive graphics processor output to one or more coupled displays. In some embodiments, display controller 211 may be a separate module coupled with the graphics processor via at least one interconnect, or may be integrated within the graphics processor 208 or system agent core 210.
In some embodiments, a ring based interconnect unit 212 is used to couple the internal components of the processor 200. However, an alternative interconnect unit may be used, such as a point-to-point interconnect, a switched interconnect, or other techniques, including techniques well known in the art. In some embodiments, graphics processor 208 couples with the ring interconnect 212 via an I/O link 213.
The exemplary I/O link 213 represents at least one of multiple varieties of I/O interconnects, including an on package I/O interconnect which facilitates communication between various processor components and a high-performance embedded memory module 218, such as an eDRAM module. In some embodiments, each of the processor cores 202-202N and graphics processor 208 use embedded memory modules 218 as a shared Last Level Cache.
In some embodiments, processor cores 202A-202N are homogenous cores executing the same instruction set architecture. In another embodiment, processor cores 202A-202N are heterogeneous in terms of instruction set architecture (ISA), where one or more of processor cores 202A-N execute a first instruction set, while at least one of the other cores executes a subset of the first instruction set or a different instruction set. In one embodiment processor cores 202A-202N are heterogeneous in terms of microarchitecture, where one or more cores having a relatively higher power consumption couple with one or more power cores having a lower power consumption. Additionally, processor 200 can be implemented on one or more chips or as an SoC integrated circuit having the illustrated components, in addition to other components.
FIG. 10 is a block diagram of a graphics processor 300, which may be a discrete graphics processing unit, or may be a graphics processor integrated with a plurality of processing cores. In some embodiments, the graphics processor communicates via a memory mapped I/O interface to registers on the graphics processor and with commands placed into the processor memory. In some embodiments, graphics processor 300 includes a memory interface 314 to access memory. Memory interface 314 can be an interface to local memory, one or more internal caches, one or more shared external caches, and/or to system memory.
In some embodiments, graphics processor 300 also includes a display controller 302 to drive display output data to a display device 320. Display controller 302 includes hardware for one or more overlay planes for the display and composition of multiple layers of video or user interface elements. In some embodiments, graphics processor 300 includes a video codec engine 306 to encode, decode, or transcode media to, from, or between one or more media encoding formats, including, but not limited to Moving Picture Experts Group (MPEG) formats such as MPEG-2, Advanced Video Coding (AVC) formats such as H.264/MPEG-4 AVC, as well as the Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1, and Joint Photographic Experts Group (JPEG) formats such as JPEG, and Motion JPEG (MJPEG) formats.
In some embodiments, graphics processor 300 includes a block image transfer (BLIT) engine 304 to perform two-dimensional (2D) rasterizer operations including, for example, bit-boundary block transfers. However, in one embodiment, 2D graphics operations are performed using one or more components of graphics–processing engine (GPE) 310. In some embodiments, graphics-processing engine 310 is a compute engine for performing graphics operations, including three-dimensional (3D) graphics operations and media operations.
In some embodiments, GPE 310 includes a 3D pipeline 312 for performing 3D operations, such as rendering three-dimensional images and scenes using processing functions that act upon 3D primitive shapes (e.g., rectangle, triangle, etc.). The 3D pipeline 312 includes programmable and fixed function elements that perform various tasks within the element and/or spawn execution threads to a 3D/Media sub-system 315. While 3D pipeline 312 can be used to perform media operations, an embodiment of GPE 310 also includes a media pipeline 316 that is specifically used to perform media operations, such as video post-processing and image enhancement.
In some embodiments, media pipeline 316 includes fixed function or programmable logic units to perform one or more specialized media operations, such as video decode acceleration, video de-interlacing, and video encode acceleration in place of, or on behalf of video codec engine 306. In some embodiments, media pipeline 316 additionally includes a thread spawning unit to spawn threads for execution on 3D/Media sub-system 315. The spawned threads perform computations for the media operations on one or more graphics execution units included in 3D/Media sub-system 315.
In some embodiments, 3D/Media subsystem 315 includes logic for executing threads spawned by 3D pipeline 312 and media pipeline 316. In one embodiment, the pipelines send thread execution requests to 3D/Media subsystem 315, which includes thread dispatch logic for arbitrating and dispatching the various requests to available thread execution resources. The execution resources include an array of graphics execution units to process the 3D and media threads. In some embodiments, 3D/Media subsystem 315 includes one or more internal caches for thread instructions and data. In some embodiments, the subsystem also includes shared memory, including registers and addressable memory, to share data between threads and to store output data.
3D/Media Processing
FIG. 11 is a block diagram of a graphics processing engine 410 of a graphics processor in accordance with some embodiments. In one embodiment, the GPE 410 is a version of the GPE 310 shown in FIG. 10. Elements of FIG. 11 having the same reference numbers (or names) as the elements of any other figure herein can operate or function in any manner similar to that described elsewhere herein, but are not limited to such.
In some embodiments, GPE 410 couples with a command streamer 403, which provides a command stream to the GPE 3D and media pipelines 412, 416. In some embodiments, command streamer 403 is coupled to memory, which can be system memory, or one or more of internal cache memory and shared cache memory. In some embodiments, command streamer 403 receives commands from the memory and sends the commands to 3D pipeline 412 and/or media pipeline 416. The commands are directives fetched from a ring buffer, which stores commands for the 3D and media pipelines 412, 416. In one embodiment, the ring buffer can additionally include batch command buffers storing batches of multiple commands. The 3D and media pipelines 412, 416 process the commands by performing operations via logic within the respective pipelines or by dispatching one or more execution threads to an execution unit array 414. In some embodiments, execution unit array 414 is scalable, such that the array includes a variable number of execution units based on the target power and performance level of GPE 410.
In some embodiments, a sampling engine 430 couples with memory (e.g., cache memory or system memory) and execution unit array 414. In some embodiments, sampling engine 430 provides a memory access mechanism for execution unit array 414 that allows execution array 414 to read graphics and media data from memory. In some embodiments, sampling engine 430 includes logic to perform specialized image sampling operations for media.
In some embodiments, the specialized media sampling logic in sampling engine 430 includes a de-noise/de-interlace module 432, a motion estimation module 434, and an image scaling and filtering module 436. In some embodiments, de-noise/de-interlace module 432 includes logic to perform one or more of a de-noise or a de-interlace algorithm on decoded video data. The de-interlace logic combines alternating fields of interlaced video content into a single fame of video. The de-noise logic reduces or removes data noise from video and image data. In some embodiments, the de-noise logic and de-interlace logic are motion adaptive and use spatial or temporal filtering based on the amount of motion detected in the video data. In some embodiments, the de-noise/de-interlace module 432 includes dedicated motion detection logic (e.g., within the motion estimation engine 434).
In some embodiments, motion estimation engine 434 provides hardware acceleration for video operations by performing video acceleration functions such as motion vector estimation and prediction on video data. The motion estimation engine determines motion vectors that describe the transformation of image data between successive video frames. In some embodiments, a graphics processor media codec uses video motion estimation engine 434 to perform operations on video at the macro-block level that may otherwise be too computationally intensive to perform with a general-purpose processor. In some embodiments, motion estimation engine 434 is generally available to graphics processor components to assist with video decode and processing functions that are sensitive or adaptive to the direction or magnitude of the motion within video data.
In some embodiments, image scaling and filtering module 436 performs image-processing operations to enhance the visual quality of generated images and video. In some embodiments, scaling and filtering module 436 processes image and video data during the sampling operation before providing the data to execution unit array 414.
In some embodiments, the GPE 410 includes a data port 444, which provides an additional mechanism for graphics subsystems to access memory. In some embodiments, data port 444 facilitates memory access for operations including render target writes, constant buffer reads, scratch memory space reads/writes, and media surface accesses. In some embodiments, data port 444 includes cache memory space to cache accesses to memory. The cache memory can be a single data cache or separated into multiple caches for the multiple subsystems that access memory via the data port (e.g., a render buffer cache, a constant buffer cache, etc.). In some embodiments, threads executing on an execution unit in execution unit array 414 communicate with the data port by exchanging messages via a data distribution interconnect that couples each of the sub-systems of GPE 410.
* Execution Units*
FIG. 12 is a block diagram of another embodiment of a graphics processor 500. Elements of FIG. 12 having the same reference numbers (or names) as the elements of any other figure herein can operate or function in any manner similar to that described elsewhere herein, but are not limited to such.
