Intel gma 3000 настройка

Intel® GMA X3000 Architecture

The GMA X3000 is designed from a new architecture which improves upon previous Intel graphics architectures through use of a fully programmable and scalable array of execution units. This scalable design allows the number of execution units to be easily increased as manufacturing capabilities improve without a major architecture change resulting in a consistent and stable platform that evolves to higher performance levels over time.

The GMA X3000 architecture marks a departure from the zone rendering architecture. While the diagram below shows that the overall system architecture remains largely unchanged, a great number of graphics improvements have been made to overcome the benefits once provided by zone rendering. The list includes a larger graphics aperture size, an increase in core clock frequency to 667MHz and an increase in the system bus speed 1066MHz.

Figure 2. Chipset layout including GMCH, ICH and main memory.

Further performance increases over zone rendering are achieved through the high level of programmability of the GMA X3000 shader execution architecture. Due to this and the ability to execute both vertex and pixel shader programs the architecture is often referred to as a “unified shader architecture”. The advantage is that the amount of processing power applied to vertices and pixels can be dynamically balanced according to the needs of a particular frame of an application. Architectures lacking unified shaders may leave vertex shaders idle while the pixel shaders are overloaded on frames that contain large triangles. Conversely, frames that contain many small triangles tend to result in idle pixels shaders while the vertex shaders are overloaded. The unified approach assigns execution units to vertices or pixels as needed and thus minimizes idle execution units and provides a better price performance ratio because theoretically the end user avoids paying for silicon that is idle much of the time.

Figure 3. G965, GM965 and G35 (X3000) Pipelines

Pipeline Stages

Performance Tips When Working With GMA X3000

GMA X3000 tends to be fill rate limited when compared to other much more expensive solutions. The simplest way to handle this is by giving users the option of selecting lower resolutions and fewer fill rate intensive effects such as shadows. Better solutions that improve the user experience are detailed below.

TIP: Provide users with options that reduce fill rate requirements.

WHY: Gen4 tends to be fill rate limited when compared to other much more expensive solutions.

HOW: The simplest way to handle this is by giving users the option of selecting lower resolutions and fewer fill rate intensive effects such as shadows. Better solutions that improve the user experience are detailed below.

TIP: Favor advanced single-pass shaders over simple multi-pass shaders

WHY: GMA X3000 tends to be more fill rate limited than compute limited. This means that when given the choice of using a simpler shader with multiple passes or a more advanced shader model with a single pass always favor the advanced shader with a single pass. GMA X3000 natively supports advanced shader models such as SM3.0. It executes them efficiently while it tends to be fill rate limited when doing multiple passes with simple shaders.

TIP: Leverage Early Z feature to reduce fill requirements

WHY: The GMA X3000 hardware can perform a Z test on a pixel before it is sent to the pixel shader or the render target; this feature is referred to as “Early Z”. If the fragment fails the Z test it can be immediately discarded thus eliminating any additional texture or frame buffer accesses.

HOW: Early Z automatically works for you whenever possible. To maximize the benefit of Early Z you should avoid manipulation of the Z buffer via pixel shaders when a standard Z test would work. Obviously if no Z test is performed before running the pixel shader you can not avoid running the pixel shader via early Z. Another common method of boosting early Z performance is to render the scene from front to back. If this can be done, it effectively reduces the depth complexity to one and thus saves substantial fill rate. However the benefits of this approach need to be balanced against the additional state changes and texture cache misses that may be incurred by forcing a total front to back ordering. Because of this it is often better to only group and sort objects that share common textures and other rendering states. Keep in mind that front to back rendering and early Z offer little benefit when depth complexity is low and or when using very simple single texture shaders.

TIP: Use Gen4’s Occlusion Query

WHY: GMA X3000 supports the D3D occlusion query capability, which can be used to reduce overdraw.

HOW: see IDirect3DDevice9::CreateQuery(). This query capability can be used to count the number of pixels that passed the Z test. With this you can determine if an object is potentially visible by rende ring its bounding box. If the query returns zero then the bounding box was not visible so there is no need to render the object. This can provide a very large performance boost when it is used on complex objects such as trees that contain hundreds of branches and leaves. The technique should not be used on simple objects since the bounding box test could be more expensive than simply rendering the object. When rendering the bounding box be sure to turn off both Z writes and color writes.

TIP: Consider Z only pass followed by color pass

WHY: When using long complex pixel shaders it’s important to minimize the number of pixels rendered so that total shader compute time stays within reason.

HOW: One way of doing this is to do an initial Z only pass (meaning no color buffer writes or pixel shader execution) for all objects in the scene. Then do a second pass with shading turned on. The early Z test will then eliminate work on all non visible pixels. This approach should not be used with simple single texture shaders since the cost of two passes can easily exceed the relatively low cost of rendering with a simple shader.

TIP: Combine the above methods for maximum benefit

WHY: These methods can work together to produce greater fill rate savings.

HOW: The Z only pass can be combined with front to back sorting to reduce Z fill requirements. Since this is a Z only pass you do not need to be concerned about state change overhead induced by sorting. Adding occlusion query with the bounding box test to the Z only pass for complex objects will further improve results. When objects are determined to be not visible in the Z pass be sure to flag them so that they can be skipped in the final color pass as well.

TIP: Reduce memory bandwidth

WHY: This will increase application performance and interactivity.

HOW: The following list describes a few methods to reduce memory bandwidth — use compressed textures, use D3DPOOL_MANAGED or D3DPOOL_DEFAULT when allocating surface, buffer or texture memory, reduce texture size or quality, use level-of-detail, reduce the content footprint by employing efficient culling algorithms.

Programming for the GMA X3000

Creating a DX9 Device and Identifying GMA X3000

Following is a code snippet that shows one way to initialize the GMA X3000 device. It shows how users can check the presence of Hardware T&L feature and turn it ON if it is available. Alternatively the sample shows how to switch to Software vertex processing for legacy integrated graphics hardware.

Device Capabilities

Listing all of the device capabilities supported by any piece of graphics hardware is a very large undertaking. The easiest way to examine a particular graphics device capability is to use the DirectX Caps Viewer, available after the DX SDK is installed on a system. This provides detailed information for each capability of the graphics card when running a DirectX driver. When using this mode, be sure to select the appropriate adapter format that represents the mode in which the graphics driver is running. For example, D3DFMT_X8R8G8B8, full screen, windowed, and so on.

Figure 4. A snapshot of the DirectX Caps viewer. On the left is a list of capability topics. On the right are the detailed caps bits reported by this hardware.

Checking for Available Memory

A check that is often performed before actually executing the application is the amount of available free graphics or video memory. As a result of the dynamic allocation of graphics memory performed by the Intel Integrated Graphics devices (based on application requests), you need to take care in ensuring that you understand all of the memory that is truly available to the graphics device. Memory checks that only supply the amount of ‘local’ graphics memory available do not supply an appropriate value for the Intel Integrated Graphics devices. To accurately detect the amount of memory available to the Intel Integrated Graphics devices, check the total video memory availability. All video memory on GMA X3000, even the dynamically allocated DVMT memory, is considered to be “Local Memory”.

“Non-Local Video Memory” will show as ZERO (0). This should not be used to determine “AGP” or “PCI Express” compatibility.

The code snippet below outlines the function calls necessary to most accurately check the memory available for use by the graphics controller within DirectX 9:

High Level Shading Languages and GMA X3000

GMA 3000 supports DirectX 9.0C/Ex. It supports the version of HLSL compiler that ships along with this DirectX9.0C/Ex distribution.

Troubleshooting GMA X3000 Issues

There are several tools available by Microsoft and other vendors to assis t in troubleshooting X3000 issues. Microsoft’s DirectX* debug runtime will send extremely useful output to your debugger. In many cases, it will even give suggestions to improve performance.

How to File a Suspected Driver Bug or Feature Request

Video-miniport, display, and 3D acceleration drivers are constantly evolving, with new features and performance improvements. Because of the complexity of these drivers, bugs will crop up from time to time. Similarly, the graphics architecture team is making decisions on what features to include in the next product, and your feedback as a customer is of tremendous value.

It is important to note that many bugs that developers believe to be driver bugs turn out to be configuration defects in their application and would occur on any hardware with similar capability. For example, if a bug appears only on Intel hardware, the problem may be an application defect that is only exposed when utilizing software vertex processing. Forcing third-party video cards to use capabilities similar to Intel devices will often expose application defects.

Should you have a feature request or a bug report to file, your first contact should be your company’s main Intel Corporation contact, typically known as a Strategic Relations Manager (SRM) or Developer Relations Manager (DRM). If your company does not have one, it is very likely that your publisher does. This should be the same person you turn to for CPU information and optimizations.

Your contact is part of a team dedicated to Software Solutions for Intel products. When they have enough investigation to suspect the problem is caused by Intel hardware or software (drivers), they will work with the Intel® Desktop Platforms Group ISV Enabling team, which will debug the problem.

Web site and Engineering support

Software developers can go to the forum at Intel® Integrated Graphics Forum and post questions/comments about the complete line of Intel’s Integrated Graphics chipset solutions.

If you are a game programmer, many useful documents including everything from multithreading to audio, are available at http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/games/index.htm .

Miscellaneous

Chipset Device IDs

Note: Device IDs are in Hexadecimal format.

Источник