shader competition results

[DeanoC]

Have you ever tried to fully detect when AA or Anistopic filtering is forced on? Its very hard, (I know because SH2PC is meant to detect AA but still fails in many cases).

I thought we're specifically talking about point-sampling shaders here...where computational results change if filtering is enabled?

Its the same whatever shader setting is changing, how do you detect something occuring at the back-end? The only meaningful way is too lock and that may give you different results. Its the quantum problem, as soon as you look the results change.

Basically its not our problem (as devs), when we select a setting in the API I expect it to be honoured else chaos erupts.

 

[Joe DeFuria]

Basically its not our problem (as devs), when we select a setting in the API I expect it to be honoured else chaos erupts.

Well, it is your problem, because devs don't pay for my video card. I do, and I expect certain things from it.

I bought my video card, and I want the ability to try and globally force AA and aniso on games that don't directly offer it. The IHV has the obligation to offer an "application preference" mode, and the IHV has the obligation to honor all dev requests in this mode. (And the app preference mode should be the default.)

As a consumer, I have the responsibility to know that forcing the control panel can give unexpected results. I do not place any burden on the software dev to ensure that the app works properly when things are forced.

At the same time, I do place the burden for AA and aniso support on the dev, if the dev wants said features supported in their game.

 

[Colourless]

My opinion, things should work like this

If point sampling is requested, and a Pixel Shader, DOT3 or EMBM is being used, then it should be honoured, always.

Under other circumstances if a control panel setting is forcing Anisotropic, I can't see any problems doing so.

Of course, as a developer, a last resort of course would be displaying a 2x2 texture checked texture fullscreen and reading back the frame buffer. If interpolation is occuring between the texels, then complain to the end user notifying them not to force filtering in their graphics cards control panel. Then disable shaders that require point sampling

 

[Joe DeFuria]

Of course, as a developer, a last resort of course would be displaying a 2x2 texture checked texture fullscreen and reading back the frame buffer. If interpolation is occuring between the texels, then complain to the end user notifying them not to force filtering in their graphics cards control panel. Then disable shaders that require point sampling

This is what I'm talking about. I don't even care if the dev goes through the trouble to disable shaders. Just perform this check at time a game is loaded, and throw up a dialog box saying the game doesn't support forced filtering, and either exit, or it's "proceed at your own risk".

 

[[maven]]

Of course, as a developer, a last resort of course would be displaying a 2x2 texture checked texture fullscreen and reading back the frame buffer. If interpolation is occuring between the texels, then complain to the end user notifying them not to force filtering in their graphics cards control panel. Then disable shaders that require point sampling

This is what I'm talking about. I don't even care if the dev goes through the trouble to disable shaders. Just perform this check at time a game is loaded, and throw up a dialog box saying the game doesn't support forced filtering, and either exit, or it's "proceed at your own risk".

But as DeanoC was saying, this is not as easy as it sounds because the lock usually triggers a different driver path!

 

[OpenGL guy]

]

Of course, as a developer, a last resort of course would be displaying a 2x2 texture checked texture fullscreen and reading back the frame buffer. If interpolation is occuring between the texels, then complain to the end user notifying them not to force filtering in their graphics cards control panel. Then disable shaders that require point sampling

This is what I'm talking about. I don't even care if the dev goes through the trouble to disable shaders. Just perform this check at time a game is loaded, and throw up a dialog box saying the game doesn't support forced filtering, and either exit, or it's "proceed at your own risk".

But as DeanoC was saying, this is not as easy as it sounds because the lock usually triggers a different driver path!

I'm confused here. A lock should show you the contents of the buffer. If you've rendered some stuff, then doing a lock on the backbuffer will allow you to examine the contents. Of course there's a different driver path taken: Lock is not normally called. However, a lock shouldn't affect the contents of the buffer unless you lock the buffer and change them yourself.

 

[DeanoC]

I'm confused here. A lock should show you the contents of the buffer. If you've rendered some stuff, then doing a lock on the backbuffer will allow you to examine the contents. Of course there's a different driver path taken: Lock is not normally called. However, a lock shouldn't affect the contents of the buffer unless you lock the buffer and change them yourself.

You'd think so... but not for some ATI and NVIDIA Dx8 drivers at least....

My (probably twisted) logic, is that we generally lock the back buffer and sometimes the filtering blit occurs in the present to the frontbuffer. So there is (at least with some drivers/some hardware etc) no AA backbuffer. Also with forced AA, I think the drivers try and return a normal frontbuffer or backbuffer on lock, so that the assumption frontbuffer.size == backbuffer.size is valid (compatibility I guess).

Don't ask me what you nasty driver people do that makes it so hard to detect, I always thought, they just had a grudge against me

 

[ET]

As a consumer, I have the responsibility to know that forcing the control panel can give unexpected results. I do not place any burden on the software dev to ensure that the app works properly when things are forced.

That's certainly appreciated, but most users apparently don't have this attitude or understanding. I mean, if I was expected to mention in the readme that AF should not be used, it means that users don't expect problems with AF. Users are likely to assume that the application or drivers have a problem, instead of understanding that overriding developer definitions can cause problems.

Perhaps this could be partially solved by having the driver pop up a warning when the user sets quality to anything other than application preference. Users should learn that these options, even though they usually work, can cause problems.

 

[OpenGL guy]

I'm confused here. A lock should show you the contents of the buffer. If you've rendered some stuff, then doing a lock on the backbuffer will allow you to examine the contents. Of course there's a different driver path taken: Lock is not normally called. However, a lock shouldn't affect the contents of the buffer unless you lock the buffer and change them yourself.

You'd think so... but not for some ATI and NVIDIA Dx8 drivers at least....

My (probably twisted) logic, is that we generally lock the back buffer and sometimes the filtering blit occurs in the present to the frontbuffer. So there is (at least with some drivers/some hardware etc) no AA backbuffer. Also with forced AA, I think the drivers try and return a normal frontbuffer or backbuffer on lock, so that the assumption frontbuffer.size == backbuffer.size is valid (compatibility I guess).

No only that, but it's unlikely that the application would understand our AA format anyway, especially if looking for a simple ARGB8888 or RGB565 format

Anyway, if you aren't doing AA, then there shouldn't be any need to translate the data.

Don't ask me what you nasty driver people do that makes it so hard to detect, I always thought, they just had a grudge against me

Paranoid, are we?