What's the deal with the HD 2900XT with Cat 7.5's AA using BF2?

Ok I see what you mean. Generally, it's easy to override like with like. In other words, if the app requests 4x AA, it'd be pretty easy to override with 8x AA. Now, I don't mean forcing 8xAA would work, though, as you could run into issues like I mentioned previously, but simply replacing the number of samples is not difficult. Note that we don't currently offer this in the control panel, since applications that offer AA generally expose all of our AA modes.

True enough, but it's still pretty easy to override like with like. For example, adaptive AA with app AA is not a problem, but adaptive AA with force-on AA runs into the same issues as normal force-on AA.

When applications start doing custom resolve filters, then it would be unwise to change the number of AA samples behind the app's back.

 

there is not exact aa sample number/mode setting in some games (like Infernal, Serious Sam 2) .

For g8x, if the enhance (application-setting) mode was seleced , the AA sample number/mode will be set as driver setting once the game turn on AA.

 

Now we're on the same page, and again I point out my discussion about "some better than none" versus "all or nothing".
Homing in on my point more precisely, what is the enumeration of the possible ways of applying AA on a surface other than the "default" determination? Is it the one allocated at a certain point in a sequence of allocations? One on which a certain action is performed? One which is associated with certain resources or specified certain flags? My thinking is that there will commonalities with flags (buffer swap methodology associated with a surface?), order (first allocation? second? last before a certain function call...), and relationships (the surface specified in association with a certain screen display or texture resource), and that such commonalities were the basis for the "specific code path" used to implement Oblivion AA, for example.

In one branch of my thinking, the "behind the scenes hacking" branch, exposing these sort of highly technical criteria via registry settings (e.g., "Allocation Order", "AllocatedWithFlag", etc.) would allow (technical) user exploration of solution to this type of problem, which would have users motivated to address these problems finding a solution that works with specific problem titles, and the package these solutions in a more easily digested form for other users. I'd prefer if the mechanism of packaging were ATI's CCC at some level, though simply exposing this type of thing via registry setting would allow things like ATT to do that.

In the other, I'm thinking that certain sets of these commonalities might not necessarily be unmanageably unique, and might be describable as solutions for implementation details ("AA of second to last 16FP surface", pardon the arbitrary description) or by a prominent engine name (could the Oblivion AA workaround approach enable AA on other titles?).

It is this latter that I would propose might be usefully exposed "up front" with sufficient prominence or commonality, but either could be used to enable a Catalyst AI related initiative to enable AA in problematic titles (in the sense that I see the simplest packaging of this type of solution as highly akin to Catalyst AI and what I understand it to be offering).

And this is what I meant by it would seem to be useful for some sort of checksum validation. Note, that with properly updated versioning resource info in released application, and file size changes, it seems that there should be ways to differentiate versions other than a complete file read and checksum calculation, perhaps by a checksum of only the data block containing file information and comparison of file size. I had thought that this type of identification would have already been useful and implemented efficiently in some way.

Right, but while the driver is what will be implementing the AA behaviors, the identification of determining the AA behavior doesn't have to go there. Is that where filename identification takes place now? What I'm proposing wouldn't have to.

OK, we are indeed on the same page, but I'm not proposing a guarantee, I'm proposing a way of approaching this that "seems like it will bear fruit".
Is there a description of the Oblivion patch does that we could discuss in this context, or any recognition of what another application might be doing wrong with regards to AA support that might shed some light on the type of criteria that might be most broadly applicable for this, or that illustrates there is no way to usefully differentiate from complete uniqueness among applications at the other extreme?

I'm not talking about simply picking one out arbitrarily, but by criteria related to how one surface might be more likely to be one that should have gotten AA if the application did things properly.

This series of answers directly addresses why my original query is not trivial, but I don't see that it addresses why it isn't reasonably possible, which is more along the lines of what I'm thinking about.

 

All HW that does AA has AA resolve of some sort, otherwise you wouldn't be able to display the data. I guess I don't know what you mean.

 

Look, if an application creates 20, 30 or maybe even 100 render targets, how are you going to determine which subset need AA in order to get everything working? You keep trivializing what is non-trivial.

Just think about what you are asking. Say we get a surface creation followed by a DrawPrimitive call and we determine that we need AA for that surface and we're going to identify it by the fact that DrawPrimitive was called immediately after. That means that if *any other* function was called first, we don't want AA. To be honest, you don't want your driver full of stuff like that. General solutions are hard, even moreso today when applications do a lot more render-to-texture and post-processing effects. Force-on AA is a relic of the past, app AA is the future. Keep harping on developers to support AA so the graphics drivers can stay lean and mean.

The driver is just that, a driver. It's not the application. It should not be responsible for rewriting the application's render engine.

There's not enough commonality between any two engines to get things working this way.

The CCC has no idea what app is going to be run when the settings are made.

If it's not going to work in general, then what's the point? We end up with a disused code path and end up writing everything by hand per-application anyway.

There is no "more likely". Either you get it right or you don't.

*Anything* is possible. Doesn't mean they are feasible.

 

All HW uses AA resolve of some sort. As I said, I don't understand what you mean.

 

"Some application have 10s of render targets. How can the driver know which one needs AA? Should all get AA?"

doesnt super sampling overcome this ?

 

ECH, you're asking your question using the wrong terminology. Yes, depending on where you want MSAA performed in your engine, HD 2900 XT could be faster than any G80 on a per-clock basis.

But you need to understand why and where R600 and how it performs AA to follow that, and it seems you don't. Someone around here wrote a review which tries to explain it, so you could start by reading that to figure out what's going on

 

No. It's the same issue: Which buffers need supersampling and which ones don't? You don't want to supersample (or multisample) everything for various reasons (performance being an important issue and also memory requirements).

 

"Is there a description of the Oblivion patch does that we could discuss in this context, or any recognition of what another application might be doing wrong with regards to AA support that might shed some light on the type of criteria that might be most broadly applicable for this,"

you should go into the pc games forum and talk to the guy who made a fssa patch for bloodrayne 2

"Development was very hard & long, cause i had to learn a lot of things like dll hooking, direct3d api, ... then, i wrote a software to trace all the calls from the game to the direct3d api. It helped me to understand how the game renders a single frame. This was the most hard part, cause, i had to find a pattern in the game calls to the api, to detect the ones that i needed to modify on the fly. The main problem for the FSAA not working with BR2, is that the game renders to a texture, and a texture can't have a AA buffer in D3D8. So, i had to change that target on the fly, to a valid surface with AA, and then update the calls that used that texture too. There's a performance hit due to all this process, but, after several optimizations, it's acceptable."

 

Not just one factor, but by a set of commonalities, so this construction doesn't reflect what I mean, however...

...I take it that based on your experience there are overwhelming issues with building a driver with this type of functionality (performance, stability?), and that your commentary reflects that in as much detail as you have time for or are allowed.

Thanks for that.

This sounds like a familiar campaigning platform...are there signs D3D 10 will get a greater portion of developers in front of the soap box?

That's not what I'm describing, but again it seems your experience is dictating a "driver bible" set of precepts that equate it with that. Disappointing with regards to what I'd hoped could be achieved, it seems.

So Oblivion's AA enabling code could not be used to get AA in any other title? I had had a vague recollection of otherwise, but I guess not.

? I wasn't discussing what the CCC does already, but what it could do, since you seem to have indicated that the driver is where filename recognition takes place (at least, by what you haven't contradicted or confirmed that seems to be the implication).

The point is when it does work, I thought was clear....? Yes, this is something that was intended to be "per-application" in focus, and I guess the process of criteria matching defined for each application is "writing everything by hand" and, as such, faces the above overwhelming issues.

More likely is in the context of being able to get it right or not among a selection of problem applications. Example: Oblivion AA versus other problem applications, is a set indicating an approach with low likelihood...my discussion is along the lines of an approach netting results for Oblivion + another app + another app + ... versus the remainder of problem applications, which is a higher likelihood, even though for each individual app "either you get it right or you don't".

"reasonably possible" seems to equate "feasible" for the purposes of our discussion, and I guess you're saying that it isn't based on your experience. Too bad, but thanks for the response.

 

This brings me back to the idea I had quite some time ago:it would`ve been better if ATi never released the Chuck patch. Now everybody and their dog is running around renaming exes of every darned thing and wondering why it doesn`t work, and why is ATi sucky and not fixing every darned engine in existence. Since OGL Guy explained it nicely, I fail to see what is so hard to comprehend. Here are two examples of why you don`t want to mess around with a general very high-level override:NWN2 and the recently released Overlord. Both of these games do a full-screen bloom effect in a separated RT(I think). If you force CP AA, that gets antialiased, and the RT in which the actual geometry&stuff is gets jacksquat, thus you`re getting a performance loss without getting any kind of improvement. Both the apps support AA, and enabling it through the game-engine produces the expected results...plus it`s cleaner than constantly messing with the CCC.

Hoping that ATi(or anyone) would stay and tweak on a per-game basis to find the proper hack(like they did with Oblivion, or like nV did with R6:V), is misplaced hope, and I pray to god that they DON`T do this. Work with devs, provide them support WRT enabling AA in their engines and so forth?Sure. Wasting precious time and resources to hack around limitations that shouldn`t be there?No.

As a funny sidenote(since the thread is already derailed beyond redemption), do you ATi guys know that the ancient RTHDRIBL demo exposes all of your AA modes, including CFAA?That was quite a surprise, but they`re all selectable(and work, the blur with the tent being indicative of them being enabled)

 

App: Enhance will provide coverage/multi sample's to the base multisample. It can be a little finicky. If an application requests 4xAA and your enhancing with 16xCSAA, It will attempt to place the additional 12x CSAA based on how the game renders AA.. Sometimes this can be effective for games that dont support control panel AA. It opens up alternative modes which arent always supported by the application such as 8x MS, 8xCSAA, 16xCSAA, 16xQ CSAA.