Tools
From AttilaWiki
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
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 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]
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.
Features
- Automatic sequential replay of the trace or "freezed-mode" using the "F" key to advance in frame steps.
- Allows dumping the current visualized frame in a Bitmap image. When automatic sequential replay, an automatic dumping of all the played frames is available too.
- Some trace directives allow to reproduce in batch steps, showing progressively how the current frame is being rendered.
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.
Features
- Plays PixRun files generated by Microsoft PIX tool.
- Controls: Play, pause, resume, advance one frame, advance one batch.
- Save/Autosave snapshots.
- Tweak some D3D9 settings when playing.
- Take many stadistics at trace, frame and batch level.
Attila Direct3D 9 Driver [Download]
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.
Features
The prototype its capable of play a simple trace, try it!
Attila Direct3D 9 Shader Translator [Download]
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.
Features
- Nice GUI :)
- Bytecode received from direct3d is correctly interpreted. An intermediate representation is build.
- Translation is partial, because many registers and instructions doesn't have an equivalent in Attila.
- A couple of instructions with equivalents in Attila are correctly translated. Examples are dp3, dp4, max, min, tex, ...
- Some instructions not natively available in Attila are translated to a emulation code. I. e. m4x4 is expanded to four dp4, sub is emulated using an add.
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:
