Probably not.

What SSAA does is roughly to say, if the monitor is 1280x1024, then we'll tell the game that it needs to render at a resolution of 2560x2048. The game engine does its work at the much higher resolution, and then once the image is done, the drivers break the pixels into 2x2 boxes, and take the average color of each set of four pixels to determine the color of a pixel that it will actually display on the monitor. That's a way to do extra work to create higher image quality, but doesn't work in reverse.

SSAA brings a penalty to performance, as it has to draw four times as many pixels for a single frame. That's why MSAA is usually used instead. MSAA finds the boundaries between polygons and says, there might be jagged edges there, so for pixels on a boundary, we'll take an average of four pixels that are off slightly and use that to draw the one pixel on the screen. For pixels in the interior of a polygon, the game just renders one pixel. The idea is to do the extra work where it makes the image look better, and not where it doesn't matter. This often gets most of the benefit of SSAA, with only a small fraction of the performance hit. It's not perfect, though, as it can't smooth jagged textures, and doesn't help much for transparent objects.

The other problem with MSAA is that, in order for it to work, the game has to know where the boundaries between polygons are. Drivers can't do this on their own, but need help from the game engine. Normally a game engine that supports MSAA will also have video options to turn it on, which is why I'm surprised that it isn't there.

MLAA is a post-processing effect, and not actually a form of anti-aliasing at all. What MLAA does is to first have the game engine render the image as normal. Then before it sends the frame to the monitor, it searches for places where adjacent pixels are very different colors. It says, maybe that's a jagged edge, and blurs the colors together to smooth it. This anti-aliases everything, so it doen't miss some parts like MSAA does. MLAA also has a performance hit roughly comparable to 8x MSAA, and far shy of 4x SSAA. The problem is that it can't tell the difference between 3D rendered stuff and a 2D HUD that is overlaid on top. So it will blur text, and that looks bad.

To return to your question, note that all of these are ways to do extra work in rendering a game, for the sake of improving image quality. Basically, you do all of the work that would normally be done, and then some extra work on top of that. That means lower frame rates. Going the other way isn't practical, as you have to do all of the work to render a frame normally just to have an image to display.

Another notable thing about anti-aliasing is that it means a lot of extra work for the video card, but not for other hardware. I just picked up this game last night, and haven't checked to see how hard it pushes a processor, but that isn't relevant for my anti-aliasing testing. I'd expect modern integrated graphics to have plenty of performance for the video card side, though. I could test it on my netbook (Zacate E-350, not Atom) sometime and see.

You're claiming that the various anti-aliasing types won't work. I'm claiming that I tried them and they do work. I have screenshots to prove it. I don't see a way to attach them here, but if there is, I can post them for you to see.

MLAA has nothing to do with DirectX. It's a post-processing effect that waits until the entire frame has already been rendered, and then it doesn't care how it was rendered. The algorithm is exactly the same, whether the screen was rendered with DirectX, OpenGL, or anything else. Indeed, not being linked to any particular API is kind of the point.

SSAA likewise isn't specific to DirectX. If a game can render at very high monitor resolutions, then it will work with SSAA. That's all that SSAA needs in order to work. And that's the real reason why AMD reintroduced SSAA with the Evergreen series: to allow anti-aliasing in games that don't support it natively.

The surprise is that MSAA also works, as that does need very detailed information about what the game engine is doing internally in order to render. Maybe Catalyst Control Center was doing something weird, like secretly applying SSAA when it said it was using MSAA. But there's definitely some sort of anti-aliasing being applied.

Ah, I see what you did. I didn't think of doing that myself. Good idea, though.

I tried running Spiral Knights on my netbook, and at maxed in-game settings, it was choppier than on my desktop, but definitely playable. I'm not sure if it's the processor or the graphics that is the limiting factor, but it could be either one. If a game is playable at maxed settings on netbook integrated graphics, then anything remotely resembling a modern gaming card should basically laugh at the game.

The game did take a long, long time to load on my netbook, though. With a Crucial RealSSD C300, that's not a storage bottleneck, so it's probably the processor.

On my desktop with a Core i7 860, CPU-Z reported that it was frequently using turbo boost to nudge the multiplier to 25, and the multiplier won't go over 22 unless at least two cores are power-gated off. I'm not sure if the program is single-threaded, or simply puts the bulk of the work in a single thread, but it certainly doesn't scale to more than two cores.