From AttilaWiki

Revision as of 18:44, 21 June 2007 by Jroca (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to:navigation, search


Attila OpenGL Emulation Framework

A goal for the ATTILA framework was to run real graphic applications on our detailed timing simulator. To this end, we developed an OpenGL framework for our ATTILA architecture (D3D is in the works). We have implemented an important part of the OpenGL API with our own C++ object oriented library and an autogenerated library of cover functions. The figure below shows the framework and the process of collecting traces from real graphic applications, verifying and simulating the trace and verifying the simulation result. Blue boxes in the picture are the pieces developed by the Attila team

Attila OpenGL emulation framwork (Attila Components in Blue)

The GLInterceptor tool uses an OpenGL stub library to capture a trace of all the OpenGL API calls and data that the graphic application is generating as shown in the figure above. All this information is stored in an output file (a trace). To allow the graphic application continue its normal execution GLInterceptor also passes on all the OpenGL commands and data to the original library. To verify the integrity and faithfulness of the recorded trace a second tool, GLPlayer, can be used to reproduce the trace on stock hardware and software.

Traces recorded using GLInterceptor can then be fed into our OpenGL stack to be run on the Attila Simulator. Our OpenGL stack bridges the gap between the OpenGL API and the ATTILA architecture translating each OpenGL call into one or more low-level control commands and maintaining and updating OpenGL state. The driver software organization is layered: the top layer manages all OpenGL state while the lower layer offers basic services to configure the graphics hardware and a basic memory allocation model. The features supported by our OpenGL library are: basic OpenGL functionality, about 200 API calls supported; ARB Vertex and Fragment program extensions; vertex arrays and vertex buffer objects; legacy vertex and fragment fixed function API emulated with library generated shader programs; texturing; stencil test, Z test and blending functions; and alpha test and fragment fog emulated using library generated shaders.

Attila DX9 Emulation Framework

We are currently working on equivalent components for Microsoft's D3D Api, commonly known as DX. We are currently writing a DX9 capture tool using Microsoft's PIX tracing infrastrucuture.

Attila D3D emulation framework (Attila Components in Blue)

Attila GLInterceptor [Download]

GLInterceptor replaces the OpenGL library and records all OpenGL commands issued by the application with all their parameter values, associated texture and vertex buffers data. This information is stored in an output file, a trace file for our simulator. All the OpenGL commands and data are also passed to the original library to continue the application execution. To verify the integrity and faithfulness of the recorded trace a second tool, GLPlayer, can be used to reproduce and validate the captured trace. In the current implementation the trace isn’t time stamped so our simulator is isolated from non GPU system related effects (CPU limitedexecutions, disk accesses, memory swapping). Our simulator uses the simulated DAC unit, as in a real GPU to the CRT or LCD, to dump the rendered frame into a file. We use the dumped frame for verifying the correctness of our simulation and functional emulation.

Attila GLPlayer [Download]

GLPlayer playing a UT2004 trace

The GLPlayer utility reproduces the OpenGL commands in the trace file on the system hardware OpenGL ICD. The frame-to-frame replay of the trace allows to compare visually the correctness of the trace with the simulator outputs.


Attila OpenGL Driver

The Attila OpenGL Driver implements the required OpenGL functionality from specs 1.4 to 2.0 to execute last generation games supporting this API. The Attila OpenGL Driver is a different approach to the OpenGL-compilant software implementation Mesa 3D Library in the sense that all the implemented features are supported in turn by the underlying Attila hardware and there is not any kind of substitute CPU emulation replacing the accelerated hardware processing.

The concrete supported features are described in the AOGL Module of the Attila Driver section.

Attila Direct3D 9 Player [Download]

Attila simulator needs traces taken from D3D games as input. The component responsible of deserialize D3D API calls from the trace and execute it again is the Direct3D Player. In the testing application the API calls are handled by the Microsoft Direct3D Runtime, so the results can be seen on screen, but in a simulation the Attila Direct3D Driver is used instead.

Traversing the input trace also gives the opportunity to gather some stadistics about how the games use Direct3D API. We can extract global stadistics and also detailed by frame or batch. The stadistics build of D3D Player dumps it to csv files for easy plotting.

Sometimes is interesting not to reproduce the same behaviour when playing a trace. A typical example is to reproduce a trace using a lower resolution for a low end graphics card. D3D Player is capable of tweak some parameters for this purpose.


Attila Direct3D 9 Driver [Download]

D3D Driver-Prototype.png

When a D3D game is simulated Attila Direct3D 9 Driver plays the role of Microsoft Direct3D 9 Runtime. It receives D3D API calls and executes proper operations on Attila Simulator, keeping D3D9 calls semantics.

So can i actually play my favourite game in Attila? The answer is no, try cedega for this ;). D3D9 Driver purpose is to allow some D3D games to be simulated on Attila, not to be a full D3D implementation. It's extension is limited by our simulated D3D games needs.


The prototype its capable of play a simple trace, try it!

Attila Direct3D 9 Shader Translator [Download]

D3D Shader Translator.gif

In Direct3D, shaders are created from an architecture agnostic assembly bytecode. The purpose of D3D Shader Translator is to receive this bytecode and translate it to an assembly code specific to the Attila's shader units architecture. To do this it's necessary to fully decodify D3D bytecode, build an intermediate representation and traverse it generating the target assembly code.

Altough it's an internal component a GUI is provided for interactive testing.


Attila Common Driver Layer (ACDL)

The ACDL module provides an abstraction of the Attila architecture hardware and allows the implementation of several on-top graphics API´s like OpenGL or Direct3D using the ACDL Services.

The ACDL abstraction layer prevents Graphics API implementations from dealing with the GPU register synchronization or GPU memory allocation of complex graphics structures like buffers and textures with different mipmap levels, giving a more friendly abstraction through generic pipeline states that can be saved and restored in a very flexible way, and high-level graphics objects like vertex buffers, streams, samplers, textures or render targets whose contents and related configuration registers are updated transparently.

More ACDL concrete features can be found in the Attila Driver section.

The ACDL specification in DOXYGEN documentation format is available here.

Attila Simulator [Download]

We have developed a highly accurate, cycle-level and execution driven simulator for the architecture described in the related ATTILA architecture section. The model is highly configurable (over 100 parameters) and modular, to enable fast yet accurate exploration of microarchitectural alternatives. The simulator is “execution driven” in the sense that real data travels through signals from box to box. A box uses the data received from signals and the data it stores on its local structures to call the associated functional module that creates new or modified data that continues flowing through the pipeline. The same (or equivalent) accesses to memory, hits and misses and bandwidth usage that a real GPU are generated. This key feature of our simulator allows to verify that the architecture is performing the expected tasks. Our simulator implements a “hot start” technique that allows the simulation to be started at any frame of a trace file. Frames, disregarding data preload in memory, are mostly independent from each other and groups of frames can be simulated independently. A PC cluster with 80 nodes is used to simulate dozens of frames in parallel. The current implementation of the simulator can simulate up to 50 frames at 1024x768 of a UT2004 trace, equivalent to 200-300 million cycles, in 24 hours in a single node (P4 Xeon @ 2 GHz).

Attila simulator parameters

The Attila GPU model is highly configurable as already mentioned. The text format configuration file bGPU.ini allows editing each of this parameters. See at the following document: