Ian Romanick

Automatic, pattern-based code generation for Mesa's compiler infrastructure has been a long standing dream. Nearly a decade ago experiments were conducted using systems like BURS and lburg. Each of these attempts encountered various insurmountable road blocks. In the intervening years, both software and GPU architectures have changed significantly. These changes have enabled a code-generator generator to be a reality. The design and implementation of one system will be presented. In addition to the successes, various difficulties and rough edges will be detailed.

During recent work to implement software double precision (fp64) support in Mesa's shading language compiler, some shaders were found to use excessive amounts of memory. One pessimal test case used over 80GiB. This talk will discuss techniques that were used to reduce that memory usage to less the 2GiB. This reduction was achieved through a combination of optimizing existing data structures, use of more compact data structures, and improved memory management. Use of tools such as Valgrind and pahole will be covered.

Developing software to run directly on hardware is hard. Implementing a simulator for the target hardware can help alleviate much of this pain. Techniques and best practices learned from several simulation environments for vastly different hardware will be presented.

Hardware is funny stuff. It is often documented to work one way when it actually works a slightly different way. Different revisions of the hardware may have different bugs that require different sets of work-arounds. Programming it even slightly incorrectly can lead to software crashes or system hangs. Sometimes some versions of the hardware work fine, but the version not on the developer's desk crashes. Failure modes are often opaque and give no clues for fixing the problem. Writing robust, reliable software to run directly on hardware is hard.

Software simulation of hardware is a technique that, in many cases, can alleviate some of this pain. Teams that develop hardware will often create a simulator as a by-product of hardware synthesis. Not ever developer is fortunate to have access to such tools. Those who do have access often find them slow or difficult to use. After all, these simulators are generally created as an aid for the hardware developers themselves. Much of the benefit of a full hardware simulator can be attained by developing the simulator independently from the hardware development. When the correct techniques are applied, it's not even that hard.

This talk will present a variety of techniques based on experience with several "home grown" simulation environments. Techniques for both developing and validating the simulator and techniques for integrating simulation in the regular development process will be described.

Three years ago a small team at Intel took on the task of rewriting the OpenGL Shading Language compiler in Mesa. One of the most fundamental design choices in any compiler is the intermediate representation (IR) used for programs. The IR is the internal data structure used for all program transformations including optimization and code generation. At the time the compiler was designed, a number of alternatives were investigated. In the end, a tree-like IR was selected. With hindsight being 20/20, this talk will present the tree-like IR that was chosen and the issues that have been found with that IR in the interim.

Every game for desktop PCs has the ability for the user to tune quality and performance settings. However, for the out-of-the-box experience, these games also need to detect the hardware installed in the user's system to select the initial settings. On Windows and Mac, there are a number of system interfaces provided for this purpose, but on Linux it is surprisingly difficult. This talk will cover some current best practices used by shipping Linux games. It will also introduce some interfaces under development to improve the current state of affairs.