Any word on if 4XS FSAA OpenGL will be implemented.

[AdamK47]

I remember reading back in February that there was a strong chance 4XS AA will be available for OpenGL in later driver revision for GF4 boards. Well, it's later and I don't see it yet. Any reason for that?

 

[Dave Baumann]

AFAIK, under OpenGL NVIDIA (and ATI now) force the OGL Multisample buffer extension to enable MSAA. I believe this is where the problem lies - the multisample buffer extension only copes with multisampling AA, and no super sampling. 4XS is a mix of both Mult and super sampling which is why I believe it does not work. To alter it would mean changing the multisample buffer extension definition via the ARB (I do seem to recall some kind of talk about super sampling in some earlier ARB notes).

 

[Reverend]

AFAIK, under OpenGL NVIDIA (and ATI now) force the OGL Multisample buffer extension to enable MSAA.

Technically, there is no "forcing" - multisampling is available in OpenGL (otherwise there would be no form of AA in the GF3/4!). But the problem as you described it is essentially, well, the problem.

 

[AdamK47]

Supersampling can be enabled mostly through software with very little support in the hardware. If supersampling is enabled prior to multisample buffer being enabled, then I don't see why it wouldn't work.

 

[Dave Baumann]

Technically, there is no "forcing" - multisampling is available in OpenGL (otherwise there would be no form of AA in the GF3/4!).

By 'forcing' I mean the driver is forcing. Multisampling is availble in OpenGL but via the OpenGL multisampling extension; if the application does not call for the multisampling extension then AA will not be used by that app - however when its enabled via the driver then the drivers are calling the extension outside of the application. Thats whats meant by 'forcing'.

 

[Rodéric]

Beyond3D (or ex) members fighting

I guess Rev is wrong this time.

 

[Grall]

Why would it matter if the FSAA is MS or SS? It's not supposed to matter to the software used at all. There isn't any approved OGL extenstion for Matrox's FAA for example...

*G*

 

[Xmas]

You cannot use the ARB_multisample extension to 'force' AA. It's the other way round, you have to 'force' AA in the driver panel to be able to really use the extension (at least for NVidia hardware). I.e. the maximum number of samples you can use with the extension depends on the level of AA you set in the driver.

So it generally should be no problem to force 4xS via the driver panel but let the application behave as if no AA was enabled.

 

[Lincoln Bauman]

I would also like to know why Nvidia uses ordered grid for their 4xAA mode.
This is about the worse sampling pattern they could have chosen, is there some hardware limitation that only allows OGMS?
I wish they would release some drivers that support RGMS.

Lincoln

 

[ben6]

Hrm , Dave Bauman and Lincoln Bauman, I hope we don't get into the situation of which Bauman said that (recalling Dave Barron, Dave Bauman, Dave B (Total VR) funny thing all have B as the first letter of their last name

 

[Dave Baumann]

You cannot use the ARB_multisample extension to 'force' AA. It's the other way round, you have to 'force' AA in the driver panel to be able to really use the extension (at least for NVidia hardware). I.e. the maximum number of samples you can use with the extension depends on the level of AA you set in the driver.

Not if the application has AA options in it - AFAIK a NWN has AA options with selectable leves and it just calls the Multisample buffer. The driver options are there for the titles that don't have AA as an option (most of them).

So it generally should be no problem to force 4xS via the driver panel but let the application behave as if no AA was enabled.

Clearly there is an issue or else they would have done it by now.

 

[Reverend]

Beyond3D (or ex) members fighting

I guess Rev is wrong this time.

Er, that is not what I'd called "fighting" or even an argument!

And I'm not wrong .

 

[3dcgi]

I would also like to know why Nvidia uses ordered grid for their 4xAA mode.
This is about the worse sampling pattern they could have chosen, is there some hardware limitation that only allows OGMS?
I wish they would release some drivers that support RGMS.
Lincoln

You're not going to see a magical driver fix to support RGMS. The pattern is most likely set in silicon. One reason to implement an Ordered Grid is it requires less hardware precision. For example a 2x2 grid instead of a 4x4 grid. The actual size may vary. More precision means more hardware and seeing as no competitor could run 4x AA well when the GeForce 3 came out the tradeoff to use an OG made sense.

 

[Xmas]

Not if the application has AA options in it - AFAIK a NWN has AA options with selectable leves and it just calls the Multisample buffer. The driver options are there for the titles that don't have AA as an option (most of them).

Really? That's strange because my multisample applications only work correctly if AA is enabled in the driver. And I'm doing exactly what NVidia is proposing in their multisampling pixel formats paper...

 

[Dave Baumann]

Thats the point of having the driver control panel options - so that games that do not have any FSAA support natively utilise AA, its not just to select the level of for games that do use the multisample buffer.

 

[Xmas]

Thats the point of having the driver control panel options - so that games that do not have any FSAA support natively utilise AA, its not just to select the level of for games that do use the multisample buffer.

Yes, that's how it should be, sadly it doesn't work like that.

 

[Dave Baumann]

Well, it most definitly activates it for games that don't natively support FSAA...

 

[Xmas]

Yes, but like I said the other way round is difficult. It works in D3D, but in OpenGL ARB_multisample the number of samples available depends on the driver settings, or I'm just doing something terribly wrong.

 

[Dave Baumann]

Yes, but like I said the other way round is difficult. It works in D3D, but in OpenGL ARB_multisample the number of samples available depends on the driver settings, or I'm just doing something terribly wrong.

Sam, I'm not well versed in the workings of the multisample buffer, but my assumption would be that the number of samples would be a parameter in - others here would likely know more, or the OGL registry would have more info.

However, I do know what the drivers are telling me. The NV (and ATI for that matter) driver panels have two optionsbeing "Allow applications to control the antialising mode" or "Manually select the antialiasing mode" (verbatim from the control panel). The first of these is just allowing the application to control the multisample buffer and hence the level of AA used (if thats what its being used for), the second overrides the applications settings - whether the application uses the multisample buffer or not it the driver will override it to the level selected in the control panel.

When you use the control panel to select the level of AA it is overriding your application settings.[/list]

 

[Xmas]

Sam, I'm not well versed in the workings of the multisample buffer, but my assumption would be that the number of samples would be a parameter in - others here would likely know more, or the OGL registry would have more info.

Yes, it is a parameter in. But if I set the number of samples in the pixel format to 4 and AA is set to 'application controlled' in the driver panel, it will simply behave like there is no multisample buffer at all.
In Direct3D you can activate multisampling regardless of what you set in the driver panel, so this 'application controlled' setting is just crap.

When you use the control panel to select the level of AA it is overriding your application settings.

See above. In D3D the control panel setting is only an initial value. The app can always control multisampling in D3D.