In this day and age, hardware without proper drivers is quite similar to Rys without a beer and whisky belly. Well aware of the merits of drivers (and, going by some...err...observations, malt based beverages), ATI's driver guys seek to maintain a constant 12 per year release rate. Occasionally you'll get a side-dish of hotfixes, and once or twice a year milestone drivers come out. Milestone drivers bring either significant new features, or major performance boosts...or both (they can also bring uber annoying bugs).

We've selected from the semi-lengthy laundry list of new features that you've probably already seen making the rounds that are, shall we say, more intriguing:

• slightly different handling of Crossfire profiles
• bezel compensation for Eyefinity
• initiation of an overhaul of the multi-GPU portion of the driver (guess which one we're the most interested in)

We'll start with the easiest to handle of the topics, which is the Crossfire profiles thingamybob...which, in our humble opinion, sort of misses the point, and suffers from a bit of NIH syndrome. In practice, as far as we can tell the mighty tool is an XML parser/binary encoder, and the plan is for ATI to handle the updating process (because a binary blob or an XML file is smaller than an entire hotfix driver) out of band of the main driver release. Whilst this is nice in theory, it's merely moving the goal posts (people will cry about the XML being 5 seconds late rather than the driver being 5 seconds late), and it remains to be seen what the exact cadence will be.

To be frank, we're not all that convinced this is the best solution (and we're still wondering why it took 4 years for it to come), but perhaps we're not really in the best of positions to gauge what the majority of users want or need from something like this.

Moving on to bezel management/compensation (this one's a 10.3 feature, so you'll have to wait a bit more), this should bring great joy to those souls that decided to enter multi-display heaven. As anyone that has been through a few relationships will tell you, adaptability is your best friend - however, it doesn't hurt if you get as much help adapting as possible. In the case of the current implementation of Eyefinity (and all solutions coming up in the foreseeable future, excluding projectors), bezels are a semi-obnoxious reality that isn't going away anytime soon, and something which has to be taken in if you want to get a piece of Eyefinity bliss. Bezel compensation comes as a means to help you adapt to them being there. Here's what currently happens (at least as far as we understand the technology):

• let's assume a 3 screen scenario, where each screen is X pixels wide, Y pixels tall and bezel width is equivalent to Z pixels
• in this case, the framebuffer would be 3*X pixels by Y pixels, and each screen would get a X by Y pixel region driven through it

The problem with this approach is that it makes the bezels painfully obvious: imagine a hand that starts on one screen and ends on the next - its length would appear to be length+2*Z (2 bezels, remember?). What bezel compensation does is alter the way framebuffer regions are distributed to each screen. To be more exact, our guess is that things happen somewhere along these lines:

• screen 1 gets subregion [0,X-1] of the framebuffer
• screen 2 gets [X+2*Z,2*X-1]
• screen 3 gets[2*X+2*Z,3*X-1]

So you're still rendering a 3*X by Y framebuffer, but by the 2*Z offset you ensure the illusion that the image continues under the bezels, rather than jumping across them...think of it like looking through a grating. Also, more importantly, think of it as a means of making it easier for your brain to adapt and ignore the bezels. Of course, one cannot hope to know all imaginable bezel sizes, as such the process of establishing them will be an user driven one - the interface seems nice and simple, so there shouldn't be any problems there.

Finally, the bit that we're the most interested in is the change in driver topology which resulted in the extraction of the multi-gpu component from each of the discrete DX and OpenGL driver runtimes and its consolidation into a separate entity. This is part of a more complex dance, for which the end-goal is a rather juicy one (sadly, we can't detail on this yet), but shorter term benefits will probably revolve around feature parity between APIs when it comes to multi-GPU.

We'd also like to think it'll make development work slightly easier and more productive...a bit like OOP was/is supposed to do - you can well think (on a fairly high-ish level) of the DX, OGL and newly born mGPU driver components as encapsulated classes that only interact via interface functions - each can do its own black magic inside its "walls", as long as the interface functions behave as expected. Hopefully, we'll soon be in a position to tell you more about this.

A thing all of you laptop wielding fellows out there will be pleased to hear is that starting with the 10.3s, you'll be able to grab updated Mobility drivers directly from ATI, and keep cadence with those unmobile desktop users. We understand that this is not yet valid for all laptop vendors (apparently some aren't hot on the idea just yet), but for most it'll be true. So rejoice, the time of hacking drivers to work on your laptop, or waiting and waiting and waiting for your laptop's vendor to provide an updated package will soon be at an end.

Along with these come a slew of other features like an ultra low power state for the slave card in a Crossfire configuration, extended support for Crossfire and Eyefinity (apparently it was only validated for a subset of games before), DisplayPort Audio and support for the new great fad du jour that is stereo 3D.