Transcript The_Evolving_Windows_Gaming_Platform

The Evolving Windows
Gaming Platform
Chuck Walbourn
Software Design Engineer
XNA Developer Connection
Microsoft
A Brief History of Windows
Windows 3.1
Windows 95
16-bit operating system on top of MS-DOS
WinG (most game developers used DOS extenders)
286 (386 recommended)
1 MB RAM (2 MB recommended)
EGA video
32-bit operating system (extended MS-DOS), with some
vestiges of 16-bit Windows
DirectX 1.0
386DX 20-MHz (486 recommend)
4 MB RAM (8 MB RAM recommended)
VGA video (640 × 480)
CD-ROM optional
A Brief History of Windows
DirectX 5.2
486DX 66-MHz (Pentium recommended)
16 MB RAM (24 MB RAM recommended)
VGA video (16-bit or 24-bit color recommended)
CD-ROM optional
DirectX 7.1
150-MHz Pentium (300-MHz Pentium II recommended)
32 MB RAM (96 MB RAM recommended)
VGA
CD-ROM or DVD drive
A Brief History of Windows
32-bit operating system based on NT codebase
(basically “Home Edition” of Windows 2000 Professional)
DirectX 8.1
233-MHz (300 MHz recommend)
64 MB RAM (128 MB RAM recommended)
Super VGA video (800 × 600)
CD-ROM or DVD drive
32-bit and 64-bit operating systems based on Windows
Server 2003 SP1 code base
DirectX 10
800-MHz 32-bit or x64 processor (1-GHz recommended)
512 MB RAM (1 GB RAM recommended)
DirectX 9 class video with 32 MB VRAM
(WDDM, 128 MB VRAM, Pixel Shader 2.0, 32 bpp)
DVD drive
Agenda
Windows Vista Overview
Windows Vista Service Pack 1
Direct3D 10.1
Rating System Changes
The 4 GB Limit
Windows Vista Gaming Features
Game Explorer
Parental Controls
(Family Safety)
Windows Display Driver Model
(WDDM)
Direct3D 10
Improved multi-channel audio
Improved widescreen support
Improved networking and IPv6
support
Some Internals Highlights
RDTSC-based scheduler accounting
New synchronization APIs
Slim reader/writer locks, condition variables,
more InterlockedXXX variants
Overhauled thread pool API
Dynamic kernel pool sizes
Kernel paged and non-paged pools no longer
fixed sizes at boot
Multimedia Class Scheduler Service
Some Internals Highlights
Security Hardening for Services
SCM privilege settings, services firewall policy,
automatic heap corruption termination
Many services disabled by default
Network-facing services hosted in distinct processes
Address Space Load Randomization
Opt-in for applications
/DYNAMICBASE linker switch in Visual Studio 2005 SP1
Applies to EXEs and DLLs
Just enable it
along with /NXCOMPAT and /SAFESEH
Common Game Compat Issues
User Account Control
You shouldn’t need admin rights to play a game!
Particularly important for MMOs / self-updaters to
resolve
Working well with UAC includes:
Embedded manifests with an execution level
SHGetFolderPath()
Authenticode signing
Do admin tasks only during setup
Do per-user tasks only during game
See DirectX SDK articles:
“User Account Control for Game Developers”
“Installation Best Practices for Massively Multiplayer Online Games”
Common Game Compat Issues
64-bit (x64) Compatibility
Does not require that your game be 64-bit native
Anti-cheat/copy-protection schemes
Usually kernel-mode drivers, which must have 64-bit native
Authenticode-signed versions
Poorly tested/written installations:
Path assumptions
16-bit code stubs
Undocumented registry tricks
Otherwise, Wow64 works well
Common Game Compat Issues
WDDM / Desktop Windows Manager
“Fake full-screen” performance problems
The DWM API can help here
DwmEnableComposition( DWM_EC_DISABLECOMPOSITION );
Assuming only DirectSound hardware buffers support
surround sound formats
Include multichannel SOFTWARE audio buffers in your fallback
chain!
Windows XP-era issues
Heaps (reads after free), undocumented registry keys, broken
DirectX version checks, obsolete API usage, etc.
Microsoft Application Verifier will find most of these!
Removed Components
After security review and app compat
analysis
DirectPlay Voice
Direct3D Retained Mode
DirectInput8’s ConfigureDevices UI
DirectSound HARDWARE buffers
Indeo codecs
WINHLP32.EXE (.HLP files)
IPX/SPX, NetBEUI
Windows Best Practices
The Games for Windows Technical Requirements
cover Windows XP and Windows Vista best
practices
Useful whether or not you carry the branding!
Includes links to detailed samples and articles in the
DirectX SDK
Microsoft’s Application Verifier will find most of
the “bad behavior” compatibility problems
Important for developers and test to use it!
Combined with proper use of the public Microsoft Symbol Server,
an excellent way to find serious bugs
Windows Vista SP1
Lots of performance and usability fixes
Gaming is mostly an issue of video driver
performance, which has improved greatly
over the past year
Application compatibility fixes
Mostly non-game products
Roll-up of hot fixes to date, including:
KB940105 - The “WDDM VA Space Fix”
KB936710, 945149 – Multi-GPU fixes
WDDM VA: <= 256 MB VRAM
0 GB
XPDM
WDDM
2GB
Code
Private memory
Aperture
Code
Private memory
WDDM
WDDM VA: >256 MB VRAM
0 GB
XPDM
2GB
Code
Private memory
Aperture
Code
Private memory
WDDM
!!!
WDDM
The WDDM VA Space Issue
With KB940105, WDDM only uses process
VA for lockable POOL_DEFAULT
allocations
Current video drivers needed in some cases
for full effect of fix
Note all WDDM VA is accounted for in your
process working set
See Gamefest 2007 talk for details
“Why Your Windows Game Won't Run In
2,147,352,576 Bytes”
Direct3D 10.1
Minor update to Direct3D 10
Requires Windows Vista SP1 and 10.1 hardware
Strict superset of Direct3D 10
All 10.1 devices must fully support 10
Direct3D 10 interfaces work identically on both 10 and 10.1
device
Extends the 10.0 API with 3 new interfaces for 10.1
class hardware features
These new interfaces cannot be
created for 10 devices
New HLSL profiles
Direct3D 10.1
Exposes new 10.1 class hardware features
MSAA per-sample shaders
MSAA depth read-back
Independent blend modes per render target
Cube map arrays
Render to block-compressed (BC) formats
If you don’t need these features, just use the
Direct3D10 interfaces and 4.0 shader profiles
Will work with 10 and 10.1 class hardware equally
Direct3D 10.1 Interfaces
ID3D10Device1
Used to create new interfaces on 10.1 devices
ID3D10BlendState1
D3D10_BLEND_DESC1 has full per-RT state
Direct3D10 only let you set blend-enable and RT write mask
per RT
ID3D10ShaderResourceView1
D3D10_SHADER_RESOURCE_VIEW_DESC1 adds texture cube
map array support
All other new features are through HLSL 4.1 profiles
New profiles: vs_4_1, gs_4_1, ps_4_1, fx_4_1
D3D10Compile* methods only support HLSL 4.0
Must use D3DX10Compile* methods for HLSL 4.1
HLSL 4.1 Shader Profiles
TextureCubeArray
New texture object for cube map arrays
GetRenderTargetSampleCount
GetRenderTargetSamplePosition
New ps_4_1 statements for per RT state sample access
Texture*.CalculateLevelOfDetail
Texture*.CalculateLevelOfDetailUnclamped
New ps_4_1 statements for per MSAA sample access
Texture*.Gather
Texture2DMS*.GetSamplePosition
Per MSAA sample access methods for x_4_1 profiles
Using Direct3D 10.1
Requires a 10.1 capable video card
Requires Windows Vista SP1
10.1 class hardware will work as 10 class hardware on
Windows Vista without the service pack
Use the current DirectX SDK
November 2007 Tech Preview
March 2008 is RTM
D3DX10, HLSL10 compiler, SDKLayers, RefRast10, and
DXUT support both 10 and 10.1
Using Direct3D 10.1
Three basic design choices:
Only use Direct3D 10
Works on 10 and 10.1 class hardware
Works on Windows Vista RTM or SP1
Only use Direct3D 10.1
Works only on 10.1 class hardware
Works only on Windows Vista SP1
Support both
Most code will be identical
Requires some optional code paths for 10.1 features
These D3DX10 helpers can simplify this implementation
D3DX10CreateDevice
D3DX10CreateDeviceAndSwapChain
D3DX10GetFeatureLevel1
Mixing 10 and 10.1
#include “d3d10.h”
#include “d3dx10.h”
IDXGISwapChain *g_pSwapChain;
ID3D10Device *g_pDevice;
…
DXGI_SWAP_CHAIN_DESC sd;
// Set to desired values
…
HRESULT res = D3D10CreateDeviceAndSwapChain( NULL,
D3D10_DRIVER_TYPE_HARDWARE, NULL, 0,
D3D10_SDK_VERSION, &sd, &g_pSwapChain, &g_pDevice
);
if ( FAILED(res) ) // Error Handling
// Bind render target from swap chain
// Set up viewport
…
Mixing 10 and 10.1
#include “d3d10_1.h”
#include “d3dx10.h”
IDXGISwapChain *g_pSwapChain;
ID3D10Device *g_pDevice;
…
DXGI_SWAP_CHAIN_DESC sd;
// Set to desired values
…
HRESULT res = D3DX10CreateDeviceAndSwapChain( NULL,
D3D10_DRIVER_TYPE_HARDWARE, NULL, 0,
D3D10_SDK_VERSION, &sd, &g_pSwapChain, &g_pDevice
);
if ( FAILED(res) ) // Error Handling
// Bind render target from swap chain
// Set up viewport
…
Mixing 10 and 10.1
// Use g_pDevice in most places as a D3D10 device
// In places where you need D3D10.1 interfaces
ID3D10Device1 *pDevice1 = NULL;
hr = D3DX10GetFeatureLevel1( g_pDevice, &pDevice1 );
if (SUCCEEDED(hr))
{
// Use pDevice1 to perform D3D10.1 operations
}
else
{
// Otherwise only 10 interfaces are available
}
Direct3D 10 Resources
Getting started with Direct3D 10
Sponsored Session on Friday 2:30pm
D3D10: Getting from 0 to 60 Hz
Room 3016, Moscone West Hall
SIGGRAPH 2007 Course #5
Introduction to Direct3D 10
Important performance guidance
Gamefest 2007 talk
“Windows to Reality: Getting the Most out of
Direct3D 10 Graphics in Your Games”
Rating System Changes
ESRB new content descriptors
UI display change - “Online Rating Notice”
“Mild” modified versions added (new GUIDs)
If any “new” content descriptor GUIDs are
populated in a GDF, then Windows Vista RTM
shows it as “unrated”
Reminder: “unrated” games are not blocked by
default, parents can change this setting
All existing ESRB ratings GDF data will
continue to be displayed in SP1
Rating System Changes
Support for Korean Game Ratings Board
(GRB) system added
GRB rating data in the GDF is ignored by
Windows Vista RTM
Existing installations won’t change ratings
systems
Windows Vista RTM Korean defaulted to ESRB
Windows Vista SP1 Korean defaults to GRB
If you have a GRB rating, populate it in your
game’s GDF
DirectX SDK Tools Support
Game Definition File Editor from DirectX
SDK (November 2007) includes all of these
SP1 changes
“Mild Language” and “Mild Lyrics” are missing
DirectX SDK (March 2008) will have them all
GDF Trace is being updated for DirectX
SDK (March 2008)
The 4-GB Limit
Physical memory continues to grow
2 GB is common for laptops, but 4 GB is happening
4 GB is becoming common for desktops, 8 GB for
workstations
Adapter cards use the 3 to 4 GB memory range
32-bit versions of Windows support up to 4 GB RAM
32-bit OSes in practice can’t really even use 4 GB
3.25, 3.33, or 3.5 GB useable RAM common with 4 GB RAM
installed
Multiple video cards tie up more memory range
0 GB
3 GB
Adapters
4 GB
The 4-GB Limit
Older BIOS implementations were not as
efficient in assigning adapter ranges
Intel’s Physical Address Extension (PAE) gives
the OS 36 bits of addressing instead of just
32 bits
In practice most drivers die horribly in 36-bit mode,
so it’s only an option for high-end servers
Windows Vista SP1 System Control Panel
changed to report “installed” RAM instead of
“usable” RAM
Limitation still there
KB929605 explains the 4-GB issue in detail
Windows x64 (64-bit)
x64 version of Windows XP
Based on Windows 2003 Server SP1 codebase
OEM only licensing
Limited driver coverage (many are still “Beta”)
128 GB of RAM
All editions of Windows Vista available in both x86 and
x64 versions
Retail license allows either
Windows Vista Ultimate retail includes x64 media,
otherwise use Alternative Media site
Microsoft logo programs mandate support for x64
8 to 128+ GB RAM
Actually, It’s a 2-GB Limit
Games can’t even use 4 GB of RAM
A 32-bit application has 2 GB of virtual
address space
Some VA is tied up by other file mappings
XPDM aperture / WDDM video mappings
EXE / DLL code files
Alignment and basing fragments the ranges
Means only multiple applications and the OS
can actually use more than 2 GB of physical
memory
0 GB
User memory
2 GB
Kernel memory
4 GB
Breaking the 2-GB Barrier
Large
Address
Aware (LAA)
32-bit
Application
Can extend your existing 32-bit application
Some code and middleware pitfalls
3 GB of VA on Windows 32-bit
Not really an option for consumer software due to
special boot modes and stability impact
4 GB of VA on Windows 64-bit (x64)
Works out of the box
64-bit (x64)
Native
Application
Runs only on Windows 64-bit (x64)
To support 32-bit means two versions of the game
8 TB of VA (with defined bits for future growth)
Poses porting challenges
Can’t use many deprecated technologies and APIs
No inline assembly, can use intrinsics or MASM x64
All DLLs must be 64-bit native
Windows x64 Advantages
Fully supports >= 4 GB of physical RAM
No “missing memory” problem
LAA 32-bit applications get 4GB of VA
No strange boot modes or stability problems
Full native support of both 32-bit and
64-bit applications
32-bit applications are not emulated
Best development platform
Managing the Transition
Short-term
use of x64
•
•
•
•
Development environment
Tools
Servers
Content pipelines
LAA
• Single 32-bit application
• Provides optional large memory usage for x64
customers up to 4 GB
• Encourages use of Windows x64 for high-end gamers
Long-term
use of x64
• Ship both 32-bit and 64-bit
• Required in order to use more than 4 GB
• Eventually can transition to 64-bit only for high-end
games
Call to Action
Work well on Windows XP and Windows Vista
UAC and x64 compatibility are the most critical
Games for Windows technical requirements are the best
guidelines available
Use the Application Verifier
That means developers, too, not just testers!
Support Windows Vista x64
Windows XP x64 Edition is a “nice to have”
Basic compatibility should be straight-forward
Consider /LARGEADDRESSAWARE or a secondary 64-bit native
version
Review “Why Your Windows Game Won't Run In 2,147,352,576
Bytes” from Gamefest 2007
http://www.xna.com
© 2008 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.