papatuelo escribió:
![[angelito]](/images/smilies/nuevos/angelito.gif "angelito")
y que por favor, sean un poco menos calientes y tragonas.The card has two 8-pin connectors, so its definitely drawing a lot of power.
papatuelo escribió:
SashaX escribió:Que AMD saque ya las 390/X
Si cumplen esas 2 premisas, se vienen 2 p'aquí.
Edito
http://www.guru3d.com/news-story/amd-fiji-xt-photo.htmlThe card has two 8-pin connectors, so its definitely drawing a lot of power.
D'OH!
.
TRASTARO escribió:Apple se lo pierde [aunque los entiendo]
Como sea, esta tabla parece la mas completa y veraz sobre el tema de Soporte a las FEATURES de Dirct3D12/DXGI12..
microsoft escribió:Direct3D feature levels
To handle the diversity of video cards in new and existing machines, Microsoft Direct3D 11]introduces the concept of feature levels. This topic discusses Direct3D feature levels.
Each video card implements a certain level of Microsoft DirectX (DX) functionality depending on the graphics processing units (GPUs) installed. In prior versions of Microsoft Direct3D, you could find out the version of Direct3D the video card implemented, and then program your application accordingly.
With Direct3D 11, a new paradigm is introduced called feature levels. A feature level is a well defined set of GPU functionality. For instance, the 9_1 feature level implements the functionality that was implemented in Microsoft Direct3D 9, which exposes the capabilities of shader models ps_2_x and vs_2_x, while the 11_0 feature level implements the functionality that was implemented in Direct3D 11.
Now when you create a device, you can attempt to create a device for the feature level that you want to request. If the device creation works, that feature level exists, if not, the hardware does not support that feature level. You can either try to recreate a device at a lower feature level or you can choose to exit the application. For more info about creating a device, see the D3D11CreateDevice function.
Dfx escribió:Yo sigo sin ver donde se quiere llegar con ZEN si va a ser según la información que se ha dado hasta ahora (50% mas de IPC, 2 hilos por core, 16 core?, HBM...).
A mi lo unico que me llama la atención es que se habla de HT inverso, que eso si podría ser una autentica revolución y parce que tanto Intel como AMD están trabajando en ello.
microsoft escribió:GPU virtual memory in WDDM 2.0
This section provides details about GPU virtual memory, including why the changes were made and how drivers will use it. This functionality is available starting with Windows 10.
Introduction
Under Windows Display Driver Model (WDDM) v1.x, the device driver interface (DDI) is built such that graphics processing unit (GPU) engines are expected to reference memory through segment physical addresses. As segments are shared across applications and over committed, resources gets relocated through their lifetime and their assigned physical addresses change. This leads to the need to track memory references inside command buffers through allocation and patch location lists, and to patch those buffers with the correct physical memory reference before submission to a GPU engine. This tracking and patching is expensive and essentially imposes a scheduling model where the video memory manager has to inspect every packet before it can be submitted to an engine.
As more hardware vendors move toward a hardware based scheduling model, where work is submitted to the GPU directly from user mode and where the GPU manages the various queue of work itself, it is necessary to eliminate the need for the video memory manager to inspect and patch every command buffer before submission to a GPU engine.
To achieve this we are introducing support for GPU virtual addressing in WDDM v2. In this model, each process gets assigned a unique GPU virtual address space in which every GPU context to execute in. An allocation, created or opened by a process, gets assigned a unique GPU virtual address within that process GPU virtual address space that remains constant and unique for the lifetime of the allocation. This allows the user mode driver to reference allocations through their GPU virtual address without having to worry about the underlying physical memory changing through its lifetime.
Individual engines of a GPU can operate in either physical or virtual mode. In the physical mode, the scheduling model remains the same as it is with WDDM v1.x. In the physical mode the user mode driver continues to generate the allocation and patch location lists. They are submitted along a command buffer and are used to patch command buffers to actual physical addresses before submission to an engine.
In the virtual mode, an engine references memory through GPU virtual addresses. In this mode the user mode driver generates command buffers directly from user mode and uses new services to submit those commands to the kernel. In this mode the user mode driver doesn’t generate allocation or patch location lists, although it is still responsible for managing the residency of allocations. For more information on driver residency, see Driver residency in WDDM 2.0.
GPU memory models
WDDM v2 supports two distinct models for GPU virtual addressing, GpuMmu and IoMmu. A driver must opt-in to support either or both of the models. A single GPU node can support both modes simultaneously.
GpuMmu model
In the GpuMmu model, the video memory manager manages the GPU memory management unit and underlying page tables, and exposes services to the user mode driver that allow it to manage GPU virtual address mapping to allocations.
IoMmu model
In the IoMmu model, the CPU and GPU share a common address space and page tables.
For more information, see IoMmu model.
