Just like Direct3D 10, Direct2D was designed to fit hand in glove with an optional debug layer that allows developers to receive rich information about design-time issues they might encounter when using Direct2D. Today, the Direct2D team is happy to announce that the debug layer is available from code gallery. For more information, and to download the layer, please see the debug layer entry in the SDK.
About the Direct2D Debug Layer
The Direct2D debug layer is an independent component that will intercept calls made from the application to Direct2D and provide feedback about various classes of errors, for example:
· Incorrect threading usage of Direct2D objects.
· Using Direct2D objects with the wrong factory.
· Incorrect parameters passed to Direct2D.
In addition, the Direct2D debug layer also provides additional warnings and informational traces about issues that an application might optionally want to address, for example:
· Using a software render target when a hardware render target might have been intended.
· Using a more expensive primitive when a cheaper one would have worked.
Using the Direct2D Debug Layer
The Direct2D debug layer is designed not to change the behavior of Direct2D when it is used. If the debug layer is installed, it will not be invoked and will not result in any performance overhead unless the application explicitly requests that the debug layer be used. To trace all issues, specify the D2D1_DEBUG_LEVEL_INFORMATION enumeration in the D2D1_FACTORY_OPTIONS structure before calling D2D1CreateFactory and run your application under a debugger.
We hope that you find the debug layer useful. We are also very happy to receive feedback about any issues you encounter during application development where you feel that a debug layer trace would have been helpful so that we can continue to improve the debug layer.
The Platform Update for Windows Vista, which is in mentioned in a
previous post, just had its final release! Find out more at the
Windows Team Blog.
This post will give readers insight into the GPU device driver distribution process in the Windows PC Ecosystem. Four driver distribution channels are outlined: Inbox, IHV, OEM, and Windows Update (WU). Future posts in this series will discuss driver migration from Vista -> Windows 7, hardware support for the various WDDM driver models and DirectX version levels, and how these differences affect DirectX developers.
Why care about drivers?
Every device on a Windows PC has its own driver: Network, Audio, Storage, USB, GPU, etc. Many customers don’t know what a device driver is while others update their drivers each month to get improved performance, reliability, and compatibility with the latest games and applications. We consider the entire spectrum of customers when supporting the Windows PC ecosystem. In order to coordinate Microsoft’s support strategy for these customers with our OEM and IHV partners, the Windows PC Ecosystem has four driver distribution channels which we’ll discuss below.
Driver Distribution Channels
Inbox drivers
Microsoft provides GPU drivers on the Windows 7 retail DVD on behalf of our top GPU IHV partners (AMD/ATI, Intel, and Nvidia). These drivers provide baseline functionality for about 75% of the GPU marketplace so that customers can have an easy out-of-box setup experience. These drivers are designed and written by the IHV, but are integrated into Microsoft’s development and test engineering processes to ensure compatibility. In addition, the integration of these drivers into the Windows build actually accelerates the OS development process itself because it allows us to identify and resolve issues more efficiently. Some technologies such as OpenGL, CrossFire, SLI, and Hybrid/switchable graphics are absent from the Inbox driver. (For more information on why certain technologies lack Inbox support, please see the Windows 7 Graphics Guide.)
GPU devices that do not have Inbox drivers are covered by WU which we’ll discuss later. If no inbox or WU driver is available, Windows will load the Standard VGA driver provided by Microsoft which implements the VESA standards. For most systems, this driver will deliver the common display resolutions on a single monitor, the Windows Basic theme without Aero, and limited power management support so the display is still usable. Below is a summary of GPU support available on the Windows 7 retail DVD.
|
IHV |
Inbox Driver Version (INF) |
Devices Supported |
Desktop/Notebook |
|
AMD |
8.56.1.0015 |
Radeon 9500 -> Radeon HD 4870
|
Both |
|
Intel |
8.15.10.1749 |
GMA 950 -> GMA X4500 |
Both |
|
Nvidia |
8.15.11.8593 |
GeForce 6xxx -> 9xxx,
GeForce GTX2xx,
Quadro (some) |
Desktop Only
(*Notebook support provided by Verde program) |
IHV drivers
The Inbox drivers provide a good baseline, but IHV’s continue to innovate and improve their products through new hardware releases and driver updates. IHV drivers may be downloaded directly from vendor websites such as www.amd.com, www.intel.com, www.nvidia.com, or loaded from a disc included in a retail package. Compared to Inbox drivers, IHV-supplied drivers are updated on a regular basis and tend to have more bug fixes, performance tweaks, and extra features such as OpenGL, CrossFire, SLI, and advanced control panel applets. Windows PC enthusiasts and hardcore gamers download the latest IHV drivers to get the best performance and compatibility with games and graphics intensive applications. For example, ATI, Intel, and Nvidia all list compatibility bug fixes and performance improvements in their latest driver release notes. Most driver updates are not necessary for most customers. But for major reliability fixes which eliminate blue screen errors or TDR hangs, IHV’s can post their drivers on WU as optional downloads and can request they be offered to customers as important updates, when applicable. This delivery mechanism allows the driver to get into the hands of many more customers as we’ll explain later.
OEM drivers
OEMs such as HP and Dell typically include customized GPU drivers on their systems which are tested exclusively with the particular hardware platform. These drivers are pre-loaded on the hard drive of shipping systems but can also be downloaded from OEM support websites. Laptop drivers typically have dozens of customizations specific to the hardware feature set and a driver INF file which associates the driver package with the exact PNPID of the hardware device.
The PNPID-level customization allows more control over driver distribution. For example, if a customized OEM driver is installed, WU will not offer end-users a generic or IHV-supplied WU driver unless it is specifically targeted for the user's system by the OEM. This scheme gives OEMs more end-to-end control over their products and streamlines product support by reducing the variability in the driver versions that can be installed. This reduced variability helps the OEM maintain a reliable and consistent experience for their customers. But there is a tradeoff: IHV’s continue to innovate with regular driver updates, but many OEM customers are not able to get those updates since the OEM won’t necessarily post them right away.
WU drivers
WU drivers provide baseline support for GPU devices which do not have Inbox drivers. If a customer is using the default Standard VGA driver after OS install or after installing a new video card, the WU client will automatically check the WU servers to see if a better driver is available for download. Depending on which WU options have been previously set on the machine, the driver may download and install automatically, or the customer may be prompted to accept the download. As new devices are released to market, IHVs and OEMs will continue to post drivers on their own support web sites and WU.
WU also provides a mechanism to widely distribute fixes for customer issues with previously installed drivers. End-users may not know about IHV or OEM websites or may not have the technical expertise or confidence to manually install drivers. So Microsoft works closely with OEM and IHV partners to address known issues and deliver updates automatically via WU. When a partner has a new driver update ready, they can post the driver as an optional download on WU. After several days of customer downloads, Microsoft analyzes reliability trends using opt-in customer feedback tools such as Windows Error Reporting. In fact, the use of these tools enables Microsoft to track reliability on all drivers regardless of the distribution channel. The data is analyzed and aggregated so noteworthy trends can be shared with IHV and OEM partners allowing them to target fixes more effectively. Based on this deep analysis, Microsoft may promote optional driver downloads to important downloads so that more customers get the fixes automatically.
Conclusion
We hope this post sheds some light on the driver distribution process for the Windows PC Ecosystem. Stay tuned for follow-up posts describing driver migration from Vista -> Windows 7, hardware support for the various WDDM driver models and the DirectX version levels. In the meantime you can look at the cardcaps.pdf document included in the latest DirectX SDK for a breakout of DirectX capabilities vs. GPU device.
Today I am pleased to announce the new DirectX MSDN Developer Center. This new site is a complete overhaul of the developer center to make it easier for developers to find the content they are looking for. Using this new site, we hope to provide the best developer content for developers making great graphics applications on a regular basis.
Right from the front page you’ll see the new design pushes the important content right to the front, including downloads, FAQs, documentation, and of course this blog J One major change with the site is that the majority of content is now provided through RSS feeds, so if you want to get the latest and greatest downloads or code samples the moment they’re available, you can easily subscribe to any feed by clicking the orange RSS button .gif "RSS Button")
.
We know that code samples are an important way for developers to learn the ins and outs of our technologies, so we are working to simplify the way developers can get the code samples for DirectX. To this end, many of our important code samples have been made available on Code Gallery for direct download. In addition, we have a showcase of the latest DirectX tutorials right on the front page.
As always, the Developer Center will provide easy access to all of our documentation. We are constantly looking for ways to improve your experience using this documentation in your development of applications, so please let us know if you have any feedback.
Thanks for reading, and I encourage you to check out the new site! Stay tuned, as we have even more underway to improve the way you access developer resources for DirectX, including forum improvements and new content!
Michael Oneppo
PM, DirectX
Direct2D and GDI are both immediate mode 2D rendering APIs and both offer some degree of hardware acceleration. This tends to cause some confusion – Why are these APIs different? How are they similar? Does Direct2D make GDI faster? How is Direct2D hardware acceleration different to GDI hardware acceleration? The goal of this post is to provide some insights into the differences between Direct2D and GDI.
Figure 1 - Direct2D compared to GDI
How are Direct2D and GDI different?
Direct2D and GDI are different in the details of what each API renders and how it goes about driving the display hardware. They are also somewhat different in their underlying design principles.
GDI renders opaque, aliased geometry (paths, lines, etc). It renders aliased and ClearType text, and can support transparency blending through the AlphaBlend API. However, its handling of transparency is inconsistent. Most APIs simply ignore the alpha channel, some use it. Very few APIs guarantee what the alpha channel will contain after an operation. Perhaps more importantly, GDI’s rendering doesn’t map easily to what a modern GPU renders most efficiently on the 3D portion of its rendering engine. For example, ROPs can’t be implemented by the blend stage of a GPU. However, alpha can. (ROPs can be implemented by copying between render targets and using look up tables or bitwise operations in the pixel shader. However, this is still slower than using the blender stage of the hardware). As another example, Direct2D’s aliased lines are designed to be implemented simply as two triangles rendered on the GPU. GDI guarantees that Bresenham’s line drawing algorithm is used.
Direct2D renders opaque, transparent, aliased and anti-aliased primitives. It has strict guarantees on how it both accepts and renders transparent content. This makes designing a modern UI with Direct2D easier and, it also allows Direct2D to render all of its primitives using hardware acceleration. Direct2D is not a pure superset of GDI – primitives that would have been unreasonably slow to implement on a GPU aren’t present in Direct2D. This should at least answer one question - Direct2D doesn’t help improve the performance of GDI, since GDI doesn’t use Direct2D. Neither does Direct2D use GDI.
How Direct2D and GDI differ in terms of architectural layering is shown in Figure 1. Direct2D uses Direct3D to obtain hardware acceleration. Direct3D in turn uses a user-mode display driver which packages up command streams. Direct3D sends these command streams and resources down into kernel mode for the hardware to process.
One large advantage of this architecture is the ease with which an application can use both Direct2D and Direct3D together.
Since Windows NT 4, GDI has run in kernel mode. The application calls GDI which then calls its kernel mode counterpart. There, GDI passes the primitives to its own driver model. This driver then sends the results to the global kernel mode display driver. Since around Windows 2000, GDI and the GDI drivers have run in an independent space in the kernel called “session space.” A session address space is created for each logon session and each instance of GDI runs independently in this distinct kernel mode address space.
How are GDI and Direct2D Hardware acceleration different?
The most important difference between Direct2D and GDI hardware acceleration is that Direct2D is layered on top Direct3D, while GDI has its own independent notion of a driver model. This driver model (the GDI Device Driver Interface or DDI) corresponds to the GDI primitives, while the Direct3D driver model corresponds to what the 3D rendering hardware in a GPU renders. When the GDI DDI was first defined in the early 90’s most display acceleration hardware targeted these GDI primitives. Over time, however, more and more emphasis was placed on 3D game acceleration and less on application acceleration. As a consequence more of the GDI DDI wasn’t implemented by the display driver and in the end, BitBlt was accelerated and most other operations were not.
This set the stage for a sequence of changes to how GDI renders to the display. The sequence is shown in Figure 2. There were also a number of additional factors that caused changes to the GDI driver model.
Increasing complexity and size of display drivers
Over time display drivers became more complex due largely to the increasing complexity of the 3D portion of the driver. Higher complexity code tends to exhibit more defects; hence it was desirable to move the driver to user-mode where a driver bug wouldn’t cause a reboot. As can be seen in the figure, the display driver has been divided into a complex user mode component and a simpler kernel mode component.
Figure 2 - Evolution of GDI display rendering
Difficulty in synchronizing session and global kernel address spaces
In Windows XP a display driver exists in two different address spaces, session space and kernel space. Some parts of the driver need to respond to plug ‘n play and power management events. This state needs to be synchronized with the driver state in the session address space. This is a difficult task and display drivers tended to exhibit defects when attempting to deal with these distinct address spaces.
The composited desktop
The composited desktop required GDI to be able to render to a surface which was then rendered by Direct3D to display. This couldn’t be done easily in the XP driver model since GDI and Direct3D were parallel driver stacks.
As a result, in Windows Vista, the GDI DDI display driver was changed to be only implemented by a Microsoft supplied driver, the Canonical Display Driver (CDD). GDI rendered to a system memory bitmap. Dirty regions were used to update the video memory texture which the window manager uses to composite the desktop.
GDI rendering in Windows 7
The chief disadvantage of the windows vista driver model was that every GDI window must be backed by both a video memory surface and a system memory surface. This results in system memory being used for each open GDI window.
For this reason GDI was changed again in Windows 7 to ensure that it does not require a system memory surface per window. Since GDI rendering requires it to read, modify and write the system memory surface, and since the CPU cannot directly access video memory, GDI was modified to render to and from a piece of aperture memory. The aperture memory can be updated from the video memory surface holding the window contents. GDI can render back to the aperture memory, and the result can then be sent back to the window surface. Since the aperture memory segment is addressable by the GPU, the GPU can accelerate these updates to the video memory surface. For example: text rendering, BitBlt with common ROPs, AlphaBlend, TransparentBlt, StretchBlt are all accelerated in these cases. In addition, some operations can bypass the aperture memory segment entirely, such as window BitBlt and ColorFill.
Contrasting Direct2D and GDI acceleration in Windows 7
Direct2D and GDI are both 2D Immediate-mode rendering APIs and both can be described as hardware accelerated. However, there are a number of differences that remain in both APIs.
Location of resources
GDI maintains its resources, in particular bitmaps, in system memory by default. Direct2D maintains its resources in video memory on the display adapter. As a result, when GDI needs to update video memory, this must always be done over the bus, unless the resource happens to already be copied into the aperture memory segment, or if the operation can be expressed directly. One exception to this is bitmaps created with the CreateBitmapFromDxSurface API which are resident in video memory. In contract, Direct2D can simply translate its primitives to Direct3D primitives because the resources are already in video memory.
Method of rendering
In order to maintain compatibility GDI performs a large part of its rendering to aperture memory using the CPU. In contrast, Direct2D is a translator that translates its APIs calls into Direct3D primitives. The result is then rendered on the GPU. Some of GDI’s rendering is performed on the GPU when the aperture memory is copied to the video memory surface representing the GDI window, or when it is otherwise possible.
Scalability
Direct2D’s rendering calls are all independent command streams to the GPU. Each Direct2D factory represents a different Direct3D device. In contract, GDI uses one command stream for all of the applications on the system. GDI’s method can result in some amortization of GPU and CPU rendering context overhead. Direct2D’s approach has little unnecessary serialization between independent command streams.
Location
Of course, Direct2D is entirely in user mode, including the Direct3D run time and the user mode Direct3D driver. GDI, in contrast, has most of its functionality in session space in kernel mode, with its API surface in user mode.
Availability of Hardware Acceleration
GDI is hardware accelerated on Windows XP, and on Windows 7 when the DWM is running and when a WDDM 1.1 driver is in use. Direct2D is hardware accelerated on any almost any WDDM driver and regardless of whether DWM is in use. There are announced plans to port Direct2D to Windows Vista. Here it will also be hardware accelerated on almost any WDDM driver. On Vista, GDI will always render on the CPU.
Presentation Model
When Windows was first designed, there was insufficient memory to allow every window to be stored in its own bitmap. As a result, GDI always rendered logically directly to the screen, with various clipping regions applied to ensure that it did not render outside of its window. In contract, Direct2D follows a model where the application renders to a back-buffer and the result is atomically “flipped” when the application is done drawing. This allows Direct2D to handle animation scenarios much more fluidly that GDI can.
Conclusion
We hope this post gives you some insights on how GDI and Direct2D work. If you have existing GDI code, that will continue to work well under Windows 7. But if you are writing new graphics rendering code, you should consider using Direct2D to leverage modern GPUs better.
For more information on interoperability between Direct2D and GDI see the following:
· A previous blog post on Direct2D interoperation
· The SDK article on Direct2D and GDI interoperation
If developers are using the debug version of D3D9 runtime d3d9d.dll from March 2009 DirectX SDK, they may notice compilation or runtime errors when developing on Windows 7 RTM.
There is a binary mismatch between d3d9d.dll from March 2009 DirectX SDK and Windows 7. To workaround, developers should be using the latest August 2009 DirectX SDK.
Some server applications need to render for scenarios like charting and sending back the generated bitmaps to users connected through web clients. During the planning of Direct2D, we decided to put the support of this scenario as one of our design goals.
Requirements of server-side renderingThere are several specific requirements for this scenario. First, usually the process is going to be run in Session 0 for security reason. Session 0 is dedicated for system processes and services, and isolated from user applications. It has higher privilege in some aspects but no privilege in interactive features (details
here). Second, most servers only have low-end graphics cards, or there may even be no graphics cards inside, thus the availability of hardware acceleration cannot be expected. Third, the application should be able to handle multiple concurrent requests efficiently on a multi-core machine.
Options of available APIsThere are three native 2D rendering APIs that applications can use in Windows Server 2008 R2: GDI, GDI+ and the new Direct2D. I will go through each of them and talk about whether they fit with this scenario.
- GDI
GDI does not support high-quality drawing. It lacks the support of anti-aliasing, which makes sloped lines jaggy. Moreover, it does not have full support for transparency, such as the support of semi-transparent brushes and pens.
GDI was not designed for parallel processing and suffers from an inefficient global lock. Windows 7 and Windows Server 2008 R2 have redesigned this lock to be more granular (details here), but based on our test results, D2D still scales better.
Another problem is that the total number of GDI handles is limited to 10240 per process and 65536 per session, because internally Windows uses a 16-bit WORD to store the index of them for each session. Stock objects are excluded from this limitation. Spawning new sessions is one way to overcome the limit, but it increases the memory usage.
- GDI+
The main problem with GDI+ for server scenarios is that it does not officially support running in Session 0. Functions that try to interact with the display device will receive errors because it is not allowed in Session 0. Other functions may also fail because even if the function doesn’t seem related to the display device, it may use some paths underneath that are forbidden.
GDI+ supports anti-aliasing and alpha-blending, thus it doesn’t have the quality issue of GDI. However, there is also a performance issue due to the locking mechanism, and no work in Windows 7 or Windows Server 2008 R2 has been done to improve it in GDI+.
- Direct2D
D2D was designed with multi-threading and Session 0 in mind from the very beginning. In most multi-threaded cases, D2D can be lock-free by using multiple single-threaded factories, one for each thread. There will be a factory-wide lock if the application has to use the multi-threaded mode of the factory, but it is more granular than those in GDI and GDI+. The impact of this lock is negligible and won’t grow exponentially when the number of threads increases.
How to use Direct2D for server-side renderingA typical server application for this scenario will generate pictures inside the memory using D2D software rendering using multiple threads where each thread draws one picture.
- Software rendering
To use D2D on a server without hardware acceleration, the key step is to use the software rasterizer by creating a WIC bitmap render target with D2D1_RENDER_TARGET_TYPE_SOFTWARE or D2D1_RENDER_TARGET_TYPE_DEFAULT. The default property will also use software rendering because WIC bitmap render target does not support hardware rendering.
- Multi-threading
Usually a multi-threaded architecture is good for server rendering. Take a banking application that generates charts for example. The typical case is that there will be many users connected to the server at the same time, and the charts they are asking for can be generated independently. When running on a multi-core server machine, it would be very efficient to create multiple rendering threads and put one charting task to each thread, so that the OS can fully utilize the CPU cores to run rendering tasks in parallel.
One concern about the design of multi-threaded architecture for D2D is how to create and share factories and render targets across threads. The following figures show three different potential approaches.
Figure 1 shows different threads sharing the same factory and render target. This architecture is dangerous even if the factory uses multi-threaded mode. The internal lock does not prevent situations like overlapping BeginDraw() and EndDraw() to the same render target, as depicted in the picture. The BeginDraw() in thread 1 will fail because the render target is being used for the drawing of thread 2. We do not support this architecture since it’s unpredictable when multiple threads are changing the state of the same render target simultaneously, e.g. setting the transformation matrix.
Figure 2 works but only has the same performance as single thread. The D2D locking in multi-threaded mode factory is in function level and all the D2D calls in the same factory will be serialized. As a result, if thread 1 tries to enter a D2D function while thread 2 is in the middle of executing another function, thread 1 will be blocked till thread 2 finishes.
Figure 3 is what we suggest for server-side rendering. A separate factory is created for each thread. The factory can be put in single-threaded mode if it’s only going to be accessed from within the thread. D2D functions in different threads are lock-free and can run in parallel. The cost of having multiple factories is much less than creating multiple D3D devices, just about 60k each for the memory.
Although Figure 3 has the best concurrency, you may consider Figure 2 for the benefit of sharing D2D resources that are created from the same factory.
- Generate an image file
Here are the main steps to generate an image file:
- Create an IWICBitmap,
- Pass the bitmap to CreateWicBitmapRenderTarget(),
- BeginDraw(),
- Use ID2D1RenderTarget::Clear() to clear the background. To have a transparent background in the output picture, use a color with 0 in the alpha channel for this function.
- Draw to the render target,
- EndDraw(),
- Set up an IWICStream that either writes to a file (InitializeFromFilename) or writes inside the memory (InitializeFromMemory),
- Use IWICBitmapFrameEncode to encode the bitmap into the picture format you want.
For a detailed example see the Save as an Image File Sample on MSDN.
ConclusionAs you can see above, using Direct2D for server rendering is simple and straight-forward. It provides high-quality and highly-parallelizable rendering that can be run in low privilege environments of the server. More information about how to use Direct2D can be found on MSDN
here.
Today on the Windows Team Blog we announced the Platform Update for Windows Vista. This is a set of runtime libraries that makes it easy for developers to target both Windows 7 and Windows Vista. I am very pleased to tell you that the Platform Update for Windows Vista includes the new DirectX package, including DirectWrite, Direct2D, Direct3D 11, updates to the Windows Imaging Components, XPS Print API, XPS Rasterization Service, and DXGI 1.1, enabling all new DirectX technologies on Windows Vista as well as Windows 7. In addition, the package provides several other libraries for Windows Vista for ISVs and developers that are transitioning to Windows 7 that make it easier to target and support a mixed customer base of Windows 7 and Windows Vista-based systems.
|
Feature |
Description |
|
Windows Graphics, Imaging, and XPS Library |
Latest iteration of the DirectX platform: Direct3D 11, Direct3D 10 Level 9, WARP, Direct2D, DXGI 1.1, DirectWrite, Windows Imaging Components, and XPS Print API, XPS Rasterization Service. |
|
Windows Automation API |
Allows accessibility tools and test automations to access Windows user interface in a consistent way across operating system versions. |
|
Windows Portable Devices Platform |
Supplies the infrastructure to standardize data transfers between an application and a portable device, such as a mobile phone, digital camera, or portable media player. |
|
Windows Ribbon and Animation Manager Library |
Includes the Windows Ribbon API, a command framework that enables developers to quickly and easily create rich ribbon experiences in their applications, and the Windows Animation Manager API, an animation framework for managing the scheduling and execution of user interface element animations. The Windows Animation Manager API can be used with any graphics platform including Direct2D, Direct3D, or GDI+. |
The Platform Update for Windows Vista will be supplied through Windows Update as a "recommended" install. The package requires Windows Vista SP2 or Windows Server 2008 SP2 or higher, and will be made available to the general public to download during the Windows 7 general availability time frame.
This package provides many cool features from Windows 7 onto Windows Vista in order to make sure developers can target the widest audience without having to wait for everyone to upgrade to Windows 7 in the next few months. That being said, Windows 7 is really the best experience we are providing and if you haven’t already, we recommend checking it out for yourself at our Windows 7 tour site. If you are a TechNet subscriber, you can even get the RTM version of Windows 7 early at the Windows TechNet site!
Starting Early
So what happens from now until Windows 7 general availability? We’ve set up a public beta for the Platform Update for Windows Vista to let developers try it out and for testing deployment. The public beta is also on Windows Update, but you must configure your machine to receive it. We’ve put all the proper setup procedures into a tool you can download off the Microsoft Download Center. Please refer to this download page for information and instructions.
Writing Applications
In order to create software that uses DirectX, you’ll need an SDK to properly target the technologies. Probably the fastest way is to get the DirectX SDK, which includes the headers and import libraries for most DirectX technologies. We just launched the August 2009 DirectX SDK which is available now. This is the RTM version to match Windows 7 and the Platform Update for Windows Vista, containing the first official release of the DirectX developer resources for Direct3D 11, DXGI, Direct2D, and DirectWrite. The DirectX SDK also includes a multitude of samples and tutorials for Direct3D, as well as the documentation for Direct3D and DXGI. Alternatively, the Windows 7 SDK is the best way to go to get started with the Windows Imaging Components. In addition, the Windows SDK includes documentation and code samples for Direct2D, DirectWrite, and the Windows Imaging Components. With these SDKs, developers can now publish and distribute applications and games that leverage all of the software and hardware features of DirectX in Windows 7 and Windows Vista.
Using the Platform Update for Windows Vista
Once the Platform Update for Windows Vista goes live, users who have enabled automatic updates will have the DirectX components installed automatically. This way, most Windows users on Windows Vista or Windows 7 will be ready to use DirectX content shortly after Windows 7 general availability.
However, not everyone will have Windows Update enabled on their machine. Our data indicates the number of people in this situation will be low, but if you want to target as many customers as possible it would be good to check. To help with this, we've included two resources in the August DirectX SDK: a technical article, "Direct3D 11 Deployment for Game Developers", which describes the Windows Update landscape in a little more detail and provides recommendations, and a code sample called the D3D11InstallHelper which builds into an executable that will execute the whole installation experience for you. In addition, the code sample also provides a set of APIs that allows you to kick off the installation of Platform Update for Windows Vista from within your application or installer. These resources install the entire Platform Update for Windows Vista, so although they reference Direct3D 11 in the name, rest assured that all of DirectX is covered. Check out the August 2009 DirectX SDK for details.
Thanks for reading, and we look forward to seeing the amazing applications you will make with DirectX!
There are many different graphics technologies in Windows, and with Windows 7 we are adding to that collection with new technologies such as Direct2D and DirectWrite. Additionally, technologies such as GDI and GDI+ continue to be used in Windows software for many applications.
As we have mentioned before, these technologies were all designed with some set of scenarios and customers in mind at some point. And many of these technologies have enjoyed success and are used by a variety of applications, some of which have a history going back more than a decade. For these reasons and more, adopting new technology typically is not done with a brand new application from scratch. Normally there is an existing body of code that either needs to be ported to a new technology, or needs to work with the new technology as seamlessly as possible.
In this post I want to cover the concept of API interoperability. For the purposes of this post, this is defined as a point in one API where resources from another API can be used. Basically, this denotes a point where the two technologies can be ‘joined together’ and is an opportunity for different versions of the same technology to work together (for example, using D3D11 with D3D10), or for technologies that do similar things to work together (for example, drawing to a GDI surface with D2D). This capability to use APIs together has always existed with DirectX, but some of the mechanisms have been more efficient than others in the past.
This post is not meant to be exhaustive – each of these points can sometimes require some depth of learning to be harnessed effectively, and future blog posts and white papers will do that. The main goal is to highlight the places where our technologies work together and discuss the philosophy we have around that moving forward.
The current landscape of DirectX technology is vast. Below is a diagram that I have created to attempt to show both existing technologies (in orange), our new / evolved technology for Windows 7 (in blue) and show an interface or method that links them together wherever possible.
Note that this “subway map” of DirectX APIs does not cover every single way of making them work together, just the main supported or advised ways of doing so. Most APIs have a way of reading and writing raw memory for surfaces, and this is always the most basic way of making two things work together. However, this method of interoperability has the weakness of not allowing good performance when video memory is brought into the picture. It also does not allow an application to take advantage of improvements in how technologies can work together over time.
There are some key concepts that should be gleaned from this diagram:
- The legacy runtimes were not the best at working together. D3D10.0 had no way to talk with GDI. D3D10.0 and D3D9Ex could share surfaces, but they had to manually synchronize. This was a known pain point for developers and is hard to do, because basically you have two different runtimes both asynchronously communicating to the hardware and knowing the state of synchronization between two APIs is difficult.
- The Windows 7 technologies are all linked in a common sense way. D2D was designed to consume WIC bitmaps easily and to draw DWrite text easily. D2D can render to D3D10.1 textures without doing any copying or GPU / CPU synchronization. And D3D10.1 and D3D11 can share surfaces between their devices without GPU / CPU synchronization. Going forward we want to keep our new technologies working together this way as a cohesive, componentized stack.
- The new Windows 7 APIs can work together with our legacy APIs. They can all talk to GDI (with D3D runtimes doing this through DXGI). This is important because so many applications are still built with GDI, and working with GDI allows incremental use of the new technology as well as an easier port of existing technology if desired. Legacy D3D runtimes can share surfaces with the new runtimes if need be as well.
Hopefully the current state of affairs is clear – we are committed to making sure that our current APIs and technologies work together as well as they can. We know that ideally every single API will work well with any other API, but the reality is that time is limited and we chose to focus on getting the new APIs to work well with GDI, since this is a known point where people need interoperability to work. We will never reach the point where we have 100% mixing of any two APIs, because not all combinations equal sense – we want to invest more heavily in the areas that have the most demand.
There are many challenges in making interoperability fast, but there are three main factors that are responsible for creating bottlenecks:
- Copying resources around in system memory – this eats memory bandwidth and CPU time, either limiting the performance or making an experience eat more resources than it should.
- Moving content between the GPU and the CPU – this can tie up the system bus, and tie up resources in managing the copy. It normally also involves similar memory access problems to the normal copying.
- Synchronizing GPU / CPU state – the normal mode of operation for GPU communication is asynchronous, because this increases performance by allowing batching up of commands. Synchronization involves flushing these commands and causing a CPU wait.
In the future our goal is to continue to make our technologies work better together at the API level, mainly through developing all of the components as a cohesive stack that works better together by design and works to remove the above bottlenecks as much as possible. This will be a challenge going forward, but designing this in at the beginning is easier than bolting it on later.
If there is a particular connection or set of connections in the above diagram that you would like to see more detail on, please leave a comment and let us know. More data about the detail that people want is very useful.
The latest alpha build of Paint.NET v3.5 is using DirectWrite instead of GDI for the Text tool if you are running Windows 7. More details and a pointer to download Paint.NET v3.5 that uses DirectWrite is available here.
Paint.NET is a graphics editing program for Windows, developed on the .NET Framework. Originally created as a Washington State University student project, Paint.NET has evolved into a powerful graphics editor with support for layers, blending, transparency, and plugins.
For applications developed using the .NET framework, there is now a way to leverage the Windows 7 DirectX APIs (Direct3D10, Direct2D, DirectWrite, WIC and Direct3D 11) from your managed applications. The Windows API Code Pack is now available on MSDN. Using Windows API Code Pack you can now incorporate the power of DirectX into your applications without having to write managed-native interop code yourself.
The Windows® API Code Pack for Microsoft® .NET Framework provides a source code library that can be used to access some new Windows 7 features (and some existing features of older versions of Windows operating system) from managed code. It also includes sample applications and API reference documents. You can build the included solution files to get the assemblies for use in your applications (pursuant to the attached license). More information about the Windows API Code Pack is here.
Channel 9 offers another medium for sharing information about the Windows technologies in a developer to developer conversation format. The videos on Channel 9 are designed to provide you additional insights into the DirectX APIs (and other Windows technologies) and take a peek at the underlying architecture. Together with the blog posts and other MSDN documentation, we hope you have all the information you need to create high-quality graphics applications on Windows 7. During the past couple of months we have been working on a number of videos on Channel 9 featuring the DirectX technologies in Windows 7. The following are already live:
Windows 7 Graphics Architecture Overview – Part 1
Windows 7 Graphics Architecture Overview – Part 2
Windows 7 Graphics Architecture Overview – Part 3
Windows 7 Graphics - WIC
Windows 7 Graphics - High-DPI
Look for more videos on the different areas within DirectX in the near future. Please check them out and send us your comments.
How does Direct2D know the "best" size of texture to use for the current video card? In the future, if new cards are released that have improved performance charateristics with larger textures, how will Direct2D scale upwards?
Direct2D is a very policy free API. It creates a texture the same size as the bitmap that you ask it to create – there are no tricks done under the covers to try and glom textures together for you, or use multiple small bitmaps to make a big one. It is up to the developer to measure the performance with the bitmap sizes used.
So what' s the plan going forward? Is D2D going to be *the* 2D API, and GDI reduced to a legacy/backwards compatibility role? (please say yes). Or are the two going to live side by side, requiring you developers to switch between them depending on which task we need to do?
Short answer: Yes.
More detailed answer: There are no plans to remove GDI from the system, and there are many applications that will continue to use GDI because the cost to rewrite everything with D2D will be too high. The vision going forward is that D2D is *the* 2D API. We are very interested in any feedback that could tell us what is blocking this going forward.
Features such as ID2D1DCRenderTarget and ID2D1GdiInteropRenderTarget::GetDC were put into the system not as a signal that D2D is meant to always augment GDI, but to enable applications to be ported gradually from GDI to D2D.
By the way, how does the decision to use DX10.1 as a base impact D3D9 applications? Most apps still use that, after all. Will they be able to make use of D2D in any way?
There are two issues here. The first is hardware support – D3D10.1 ships with D3D10Level9 in Windows 7, and this allows D3D10.1 to utilize D3D9 hardware through D3D9 drivers, bypassing the D3D9 runtime entirely. This allows D2D and other applications to use the capabilities of D3D10.1 while still having reach with hardware.
The issue of using D2D to (for example) draw to D3D9 textures is something that is supported, but requires more code than using D3D10.1. This will be covered in more detail in future white papers and blog posts.
Going forward we anticipate that new applications will be written with D3D10.1 so that features like WARP can be taken advantage of.
Hi, where can I find information about when the final version of Direct2D/DirectWrite is being released? I need at least a time frame.
When will DirectX 11 be available for Vista? What is the redistributable vehicle for D3D11, D2D, DirectWrite and when will the RTM redistributable for Vista ship?
The final versions of all of the new DirectX APIs (including D2D, DirectWrite, WARP and D3D11) will ship first with Windows 7, and will be made available on Vista afterwards. We are still in the process of finalizing the dates and the logistics for downlevel - stay tuned to hear more from us. You can read more about our Windows 7 shipping plans here:
http://blogs.msdn.com/e7/archive/2009/05/11/OurNextEngineeringMilestone2.aspx
MSDN has just published a new article about Direct2D on its web site. The article is written by Kenny Kerr and features some insights from Direct2D team member Mark Lawrence. You can check it out here:
http://msdn.microsoft.com/en-us/magazine/dd861344.aspx
If you're working on porting a project from Windows 7 Beta to work with the Windows 7 Release Candidate, there are a handful of breaking changes in Direct2D and DirectWrite that you'll need to be aware of. We've documented these changes on MSDN for reference:
