This is a proposal for a new discussion group called 'fps' (Frames Per Second). Its focus is to obtain consistently high frame rates for Linux desktop applications.
The goal of consistently high frame rates cuts across many areas of Linux development, including application development, Gui toolkits, X server issues, a number of areas of the Linux kernel (mtrr and scheduling being the most visible), hardware design and configuration, and possibly the design of new hardware that is optimized with Linux in mind. Consequently, the focus of the list addresses people from many different communities. Thus, the fps discussion would not fit easily within any single existing forum (that I know of, anyway).
The purpose of the mailing list is to improve communication between the different groups involved, and to foster the knowledge that's needed to bring truly high performance to the general Linux desktop. I've definitely experienced the lack of communication - the first time I heard about mtrr write combining is when someone posted results to my GdkRgb survey page. Yet, this is perhaps the single most important improvement in Linux graphics performance in a while. As the developer of GdkRgb, I should have found out about this earlier.
One of the primary elements of the 'fps philosophy' is that a high frame rate isn't simply the number of frames that can be displayed in one second, but also includes delivering those frames at a consistent rate and with low latency. Thus, a better working definition of 'frames per second' might be the inverse of the maximum delay between frames. This effect is especially visible in jerky animations, but shows up as uneven cursor motion, jerky scrolling, and a feeling of sluggish response.
Lots of applications can benefit from high frame rates. Animation and games are simply the most obvious. My own personal interest is in highly responsive desktop applications with relatively sophisticated graphics displays (i.e. antialiased fonts and vector graphics, "themes," transparency, etc.). Image editing applications (such as the Gimp) primarily need an absolute minimum latency, so that they appear to respond instantly to the artist's pen. Some of the issues carry over into other areas of multimedia, especially sound.
Here is a list of some of the open areas I percieve:
- Why is X shared pixmap support about 15% faster than shared images? This seems to imply to me that shared images are at least 15% slower than they could be.
- Linux seems to stall processes for 100ms or more when the system is heavily CPU-loaded. How can this be reduced?
- In the 2.0.xx kernel, direct framebuffer access is roughly twice as fast as X. Is it possible to improve the X server to reduce this gap?
- mtrr is only supported on Pentium Pro and II processors. Is it possible to do something similar on other chips? It's interesting to note that GdkRgb performance is fairly poor on non-Intel Unix platforms, even SGI's.
- Is it possible to design an X extension that provides high speed graphics access (without the root-permission problems of dga)?
- What's the best way to use SMP to improve fps? Is there a good way of scheduling one thread per processor? How to minimize cache conflicts and optimize interprocessor communication?
- Are there graphics boards that exhibit particularly good performance (preliminary results from my survey indicate no)? Could there be?
Because the topic brings together people from diverse communities, keeping a consistent focus is important. Yet, it must be open, to be consistent with the Linux spirit and to make sure that everybody who can contribute is able to. Here's what I propose, based on past experience with mailing list administration:
- Host the lits on egroups.com, which has a nice archive and spam-blocking features. This minimizes the amount of admin work needed, too.
- Have a very tight charter. This is a list for getting work done, not for speculating, whining, or having holy wars. Go to /. for that.
- Have a couple of "bouncers" who warn people when they stray off-topic, and kick people who consistently violate the charter.
Thus, I hope that this will be a good list for getting maximum performance out of Linux, while respecting that the people who are doing this work are busy.
Comments welcome.
Raph Levien <raph@acm.org>
The list has provisionally been set up on egroups.com, and you can subscribe on the web:
www.levien.com