Rage3D Assassin's Creed - DX10.1 Addendum
By Alex 'Morgoth Bauglir' Voicu - reviews@rage3d.com
April 29th, 2008

[ Print ] - [ Close ]

Assassin's Creed DX10.1 - Addendum

Soon after Rage3D's initial Assassin's Creed DX10.1 investigation, Ubisoft announced the removal of DX10.1 support from the game via an upcoming patch. With little detail into the reasons of removal, the official statement on the cryptic side, questions regarding the differences in Image Quality (IQ) between the DX10 and DX10.1 pathways prompted us to investigate further. This took a bit more time than originally planned due to two reasons:

Test Setup Notes

The screenshots on the following pages are outputted by the same 3870X2s used in the initial Assassin's Creed article. We have moved to the 8.490 Catalysts, build date 09.04.2008, simply due to the reason that these allow enabling AF in-game as opposed to forcing it through the CCC. Otherwise, there are no notable differences compared to the 8.471.1 Hotfix drivers used during our prior testing.

Due to the nature of this investigation, we felt it important to offer our readers screenshots of a much higher resolution than the norm, allowing them the ability to see the minute detail necessary to make sound judgments as to the costs and/or benefits of DX10.1.

With that out of the way, lets get on to the interesting stuff.


Detailed Comparisons

In this section we'll take a close look to a few pictures, comparing them through MS PIX's inbuilt image comparison tool by subtracting (SUB) the DX10 picture from the 10.1 one.  For further testing, feel free to use XOR (exclusive OR) or XNOR (inverted XOR), but we've excluded those screenshots because, frankly, they're very hard on the eyes.

Animus Menu Comparison

DX10 shot
Menu - DX10 1920x1200 - 3.6MB
DX10.1 shot
Menu - DX10.1 1920x1200 - 3.6MB
MS PIX shot
Menu - MS PIX 1920x1200 - 1.4MB

Ah, the menu shot! This one has stirred quite a bit of ruckus, getting uninterested independent third-parties to analyze the shots we had included before in-depth. Unfortunately, whilst those shots were more than adequate for showing the effect DX10.1 had on AA quality, they weren't useable as a basis for overall image quality comparisons, given the fact that they were taken at slightly different angles. As a consequence, we felt obliged to fix our error, and not let the analyzing we talked about go in vain, by opening the this comparison with captures fit to be compared.

Looking at the differences underlined by MS PIX, the only notable difference is the better AA'd lower part of the visor. The DNA chain and the menu items are animated and thus the pictures grabbed them at points of their cycle, that's why they show up as different.

Acre Assassin's Office Comparison

DX10 shot
Acre - DX10 1920x1200 - 3.6MB
DX10.1 shot
Acre - DX10.1 1920x1200 - 3.6MB
MS PIX shot
Acre - MS PIX 1920x1200 - 1.4MB

The situation is fairly similar with the first in-game shot used, with the only notable differences being the edges that get extra AA and the animated elements in the scene, like the fountain or the GPS (Altair included: for an assassin, this guy certainly has issues standing still, and as you can see he's in a slightly different position).

Solomon's Tomb Comparison

DX10 shot
Temple - DX10 1920x1200 - 2.9MB
DX10.1 shot
Temple - DX10.1 1920x1200 - 2.8MB
MS PIX shot
Temple - MS Pix 1920x1200 - 2.2MB

This is where things get tricky, as alongside the usual effect of improved AA quality, we also get two other differences:

First, the 10.1 shot lacks the pillar of rising dust that's present with the earlier API. This is tied to having AA enabled, as with it disabled the dust renders just OK. Chances are that this is a driver bug, and we've already asked ATi about it-as soon as we get a reply you'll be the first to know. On the other hand, one of our (and probably everyone's) favorite developers, Emil Persson aka Humus, made a guess as to what might be happening that seems to align fairly well with what we're seeing:

"Interesting. I checked out the dust and it looks very much like it’s soft particles. This means they require the depth buffer for this effect. That it doesn’t work with AA makes sense too. If they simply bound the depth buffer as a texture they would need to use the Load() function rather than Sample() to fetch the depth value when it’s multisampled (any single sample in the AA depth buffer should be good enough for soft shadows, no need to average). They would also need a separate shader for each AA setting, like one for 2x, 4x and 8x. I would guess it’s broken because this wasn’t done and they are trying to sample the MSAA buffer with Sample() using the same shader as in the NoAA / plain DX10 case. Given that the effect is quite subtle it could easily have been overlooked. So fixing this (and anything else that might be broken) is probably the reason why they said they needed to redo the DX10.1 path."

The second difference is somewhat more subtle, and it has to do with HDR lighting: with 10.1, it appears somewhat more intense. This is another behavior we've come to notice whilst going through the game (which was missed until we dwelt further into comparing the two paths). What's odd is that the way the 10.1 renders is identical to the way DX9 renders, with DX10 being the outlier. Given the fact that other GPUs display a similar pattern(DX9 being brighter than DX10), and collaborating that with UBi's statements that rendering between the paths should in theory be equal visually, it looks likely that there's actually a bug with the DX10 pathway itself, that is fixed in the 10.1 one-assuming that the way DX9 renders is the look the devs are looking for.


Screenshots & Conclusion

The next pictures aren't going to include a comparison photo, simply because there was enough variation between them to make it irrelevant. Keep your eyes wide open, and establish if you're being "shafted" by using the 10.1 path - if so, running it should be avoided in order to keep the quality of the experience as elevated as possible. If that is not the case though, enjoy it!

DX10 shot
DX10 - 4.7MB 1920x1200
DX10.1 shot
DX10.1 - 4.7MB 1920x1200
DX10 shot
DX10 - 3.5MB 1920x1200
DX10.1 shot
DX10.1 - 3.4MB 1920x1200
DX10 shot
DX10 - 3.2MB 1920x1200
DX10.1 shot
DX10.1 - 3.6MB 1920x1200
DX10 shot
DX10 - 4MB 1920x1200
DX10.1 shot
DX10 - 3.7MB 1920x1200

Conclusion

Did we find the glitches that everyone has been talking about when making reference to the 10.1 path? In a way - we do have that missing dust that qualifies for that category, albeit we don't know yet if it's simply a driver bug or something wrong with the pathway itself. Other than that, there's the more intense lighting, but that actually seems to show that there's a bug with the DX10 pathway, given the fact that DX9 has the same, more intense, lighting as 10.1, and UBi said that 9 and 10 (and by extension 10.1) should be nearly identical visually (shadowing is different between versions).

The good news is that the dust-bug affects only a few scenarios and that, after testing with a run through Acre that avoids any areas which include the troublesome dust, we've determined that the performance benefits associated with 10.1 remain: it wasn't a case of the missing effect causing the performance improvements. This means that you can  safely enjoy running your game through the DX10.1 pathway without fear that you're getting worse IQ (you'll be missing some dust, at least for now).  More importantly, perhaps, the dust-bug fix should be trivial to implement - perhaps UBi, in light of recent interest with regards to the 10.1 path, will opt for fixing it right away as opposed to disabling the pathway just to re-enable it at some later undetermined point in time. From our perspective, this would certainly make the most sense. Rest assured that all further info on the topic will be presented as it becomes available to us.

Note: As we were preparing to publish, ATi released a new driver set aimed at improving 3DMark Vantage performance. What isn't mentioned is that these drivers also add official Crossfire support for AC whilst fixing the issue with application-controlled AF, giving us reason to believe that further improvements are bound to be included in future driver releases.