16 bits ZBuffer + native aniso?

This forum is for general developer support questions.
User avatar
Karlos
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 84
Joined: Sun Jun 19, 2011 11:42 am
Location: United Kingdom of England and anybody else that wishes to remain.

Re: 16 bits ZBuffer + native aniso?

Post by Karlos »

Some further points to note. Anisotropic filtering can burn up video memory bandwidth due to the number of texture samples required and have an adverse effect on performance on lower end cards. Consequently, the plan is to keep the MaxAnisotropic environment variable so that the end user can restrict the maximum degree of anisotropy that the driver will allow. If the user sets this variable to 8x and the developer tries to set a higher value, the end user's value will take precedence.

Similarly, the environment variable option to force anisotropic filtering will be retained so that old applications can be made to use it in order to improve the rendering quality for older titles.
AmiDARK
Posts: 40
Joined: Thu Oct 20, 2011 9:23 am

Re: 16 bits ZBuffer + native aniso?

Post by AmiDARK »

I agree with you on some points but, I'd like to detail more what I think is best :

1. Only applications that do not handle Anisotropic filtering will have it set with env (or from the special folder for the application if user want).

2. Application that handle Anisotropic filtering must be able to override env settings.
Why ? Simply because the end user that will for example play a game can be able to choose between quality/performance.
I remind this in an online game I play on PC : "The Lord of the Ring Online" where you can choose (in real time) to turn on/off the anisotropic filtering and, you can modify the effect value in realtime too.
Sometimes, when I get a slowest PC than I actually have, when I wanted to make nice snapshots of the game environment, I put graphics quality to maximum, get the snapshot and then restore settings to less quality/more performance. Do you understand ?
An application must always have the capability to choose on all capabilities the video card have. No ENV restrictions. They can be forgot by the user that may not understand why it don't work. When the setting is in the application, he know exactly what he changes for quality or performance or balance between both.

What does this mean in simple answer :
When Warp3D open a display, default ENV (or app default ENV) is applied.
Is the application change the anisotropic value when running, it will not modify the ENV file but it will change the displayed result with what the application defined (and no more what the ENV said).

Regards,
AmiDARK
Sam440EP - AmigaOS 4.1 Final Edition
User avatar
Hans
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 703
Joined: Tue Dec 21, 2010 9:25 pm
Location: New Zealand
Contact:

Re: 16 bits ZBuffer + native aniso?

Post by Hans »

AmiDARK wrote: 1. Only applications that do not handle Anisotropic filtering will have it set with env (or from the special folder for the application if user want).

2. Application that handle Anisotropic filtering must be able to override env settings.
I disagree. I'm a strong believer in giving the user as much control over his/her machine as possible. If a user chooses to override a program's settings, then those settings should be overridden (even if you provide warnings of any risks).

Warp3D's ENV vars allow users to override settings. If an application already provides quality vs performance adjustments, then there is little to no incentive to use the ENV vars. However, if the user still chooses to override the application's settings using the ENV vars, then the computer should obey.

Hans
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
User avatar
Karlos
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 84
Joined: Sun Jun 19, 2011 11:42 am
Location: United Kingdom of England and anybody else that wishes to remain.

Re: 16 bits ZBuffer + native aniso?

Post by Karlos »

@AmiDARK
When specified, user environment variables will take precedence. This is to ensure that the end user has final say. It's his system, after all. And as Hans points out, when an application gives the user the opportunity to control these settings directly, it isn't likely he's then going to set the corresponding environment variable as there's no need.

On the other hand, I forced 16x anisotropic sampling on just for WipeOut2097 and it looked a lot better;)
AmiDARK
Posts: 40
Joined: Thu Oct 20, 2011 9:23 am

Re: 16 bits ZBuffer + native aniso?

Post by AmiDARK »

Warp3D's ENV vars allow users to override settings. If an application already provides quality vs performance adjustments, then there is little to no incentive to use the ENV vars. However, if the user still chooses to override the application's settings using the ENV vars, then the computer should obey.
So if I'm not wrong :

1. When an application open a Warp3D display, default Warp 3D ENV settings are applied or Warp 3D application setting are applied if they exist overriding default Warp3D settings.
2. If this application try to override settings, application settings will be applied depending on 3. and 4.
3. Application settings can use higher values than default Warp3D ENV parameters.
4. Application settings cannot use higher values than application folder specific ENV parameters

Right ?
if these 4 statements are true, then I'm Ok.
(even if I found stupid that we have Two times the same parameters for 1 applications making user capability to be lost ununderstanding settings priorities ).

Kindest Regards,
AmiDARK
Sam440EP - AmigaOS 4.1 Final Edition
Crisot
Posts: 17
Joined: Fri Jan 04, 2013 12:43 pm

Re: 16 bits ZBuffer + native aniso?

Post by Crisot »

3. Application settings can use higher values than default Warp3D ENV parameters.
No, If I understand correctly, application setting can't override "default" ENV vars (your 3.), not more than "app" ENV vars (your 4.). But "app" ENV vars got priority other "default" ENV var.

It's the exact same on PC, where catalyst can override any parameters, by default settings, or by game profil (game profil override default settings), except they got an interface (and we can also make it).

It's up to user to create game profils but don't touch default parameters.
AmiDARK
Posts: 40
Joined: Thu Oct 20, 2011 9:23 am

Re: 16 bits ZBuffer + native aniso?

Post by AmiDARK »

Crisot,
It's up to user to create game profils but don't touch default parameters.
Honestly, do you often modify your Catalyst settings for each application ?
It's easier for USER to leave it control how the graphic card render 3D directly in the application...

More to this, per default, these kind of parameters are set to "leave application choose". Why ?
Because on PC world Anisotropic is available from a long time so settings "leave application choose" fit for all applications.
On Amiga, we're not in the same case where NO application handle this so the user will have to force these parameters manually.
And, with the arrival of new applications that can handle this, it will fake performance results because defined in relationship with applications that does not handle this...
More to this, never forget "think like an user and not like a developer"... if User don't use an option every days .. he will forget it ... and these kinds of options are options can be easily forgotten and may lead to unexpected results in applications. That's why having them in the application (+ ENV) is I think, the best solution.

It's just my point of view to show a different way of thinking that is not BAD (too).

Regards,
AmiDARK
Sam440EP - AmigaOS 4.1 Final Edition
User avatar
Karlos
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 84
Joined: Sun Jun 19, 2011 11:42 am
Location: United Kingdom of England and anybody else that wishes to remain.

Re: 16 bits ZBuffer + native aniso?

Post by Karlos »

It sounds like there's some confusion over this issue. Allow me to try and clarify.

In a perfect world, the full Warp3D API would be implemented fully by every driver, every application would always query the driver capabilities and the API would be upgraded over time in a perfectly backwards compatible way.

However, in reality, the situation is that different drivers do not implement the API fully. Even worse, some drivers implemented parts of the API wrongly and applications were written (that will never be updated) that expected the wrong behaviour. When these things were fixed, those old applications started getting strange bugs, crashes etc.

Most of the environment variables are there to deal with these sorts of problems. They don't have any developer side equivalent and nor should they. When the user sets them, they are enforced and there is nothing the application code can do to override them and hopefully their application works as expected again.

The Z buffer environment was added to save video memory. My 32MB R100 board choked on a lot of titles that my 256MB (128 used) R200 would run just fine simply because of the lack of VRAM and the resulting texture swapping.

Anisotropic filtering was added as an experiment, to see if it gave any visual improvement. You have to force enable it via the environment vars for the moment since there is no other way to activate it.

When the API is updated, the behaviour will be as follows:

If the user enables anisotropic filtering via "force" through the env vars, it will be enabled and cannot be disabled by the application itself. This option is not for new software that will be anisotropic-aware, it is for everything that was written up to now that has no knowledge of it.

Regarding limits, such as the degree of anisotropy, the order of priority shall be:

Hardware Limit > app profile env limit (if any) > 3) global env limit (if any) > API request

Consider the following use cases:

1) Running an old game that has no knowledge of anisotropy but the user wants to have 8x anisotropy. He'd need to do the following:

SetEnv SAVE Warp3D/RadeonR200/<app>/Anisotropic force
SetEnv SAVE Warp3D/RadeonR200/<app>/MaxAnisotropic 8

The game will now use the closest anisotropic equivalent to whatever texture filters the game asked for, with a sample limit of 8x.

2) Running a new title that directly supports these features and gives the user control over their settings. The user will simply use whatever in-game options are available. No environment variables are required.

3) Running a new title that directly supports these features but doesn't give the user control over their settings. Suppose the game simply sets everything to the max because that's what the developer thought looked best and worked on his machine (tm).

In this case, a user might find that his card can't cope with that level of detail. He can now use the environment variables to reduce the settings to something he prefers:

SetEnv SAVE Warp3D/RadeonR200/<app>/MaxAnisotropic 8

In this case, when the game tries to set the anisotropy level for any texture to be more than 8x, it will be clamped at 8x. It can still set the anisotropy to be lower than 8x for a texture and that's OK.

Other drivers have user-defined limits too. For example, the Permedia2 chip can support textures of 2048x2048, but a 32-bit texture that size is already 2x larger than the total VRAM the card supports. The user can set an environment variable (ENV:Warp3D/Permedia2/<app>/LimitTextureSize) to restrict this size so that any applications which (properly) query the driver for the information will see whatever value they set, rather than the theoretical limit.
User avatar
Hans-Joerg Frieden
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 223
Joined: Wed Dec 08, 2010 3:52 pm

Re: 16 bits ZBuffer + native aniso?

Post by Hans-Joerg Frieden »

AmiDARK wrote:Crisot,
It's up to user to create game profils but don't touch default parameters.
Honestly, do you often modify your Catalyst settings for each application ?
It's easier for USER to leave it control how the graphic card render 3D directly in the application...
The Catalyst drivers usually come with pre-set profiles for games, and most games I know on the PC have a setting for the texture filtering, so you can actually switch it in game and do not need to go for the control panel.

Usually, it's easier for the user if the defaults are good, but once you get into performance issues, it's better the user can actually influence some parameters to make the game workable on their machine. That's better than the user not being able to use it.
NOTICE: If you want to contact me, use E-Mail. I cannot be contacted via the forum/private messages anymore
User avatar
Karlos
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 84
Joined: Sun Jun 19, 2011 11:42 am
Location: United Kingdom of England and anybody else that wishes to remain.

Re: 16 bits ZBuffer + native aniso?

Post by Karlos »

AmiDARK wrote:if User don't use an option every days .. he will forget it ... and these kinds of options are options can be easily forgotten and may lead to unexpected results in applications. That's why having them in the application (+ ENV) is I think, the best solution.
This is why we have user documentation: http://wiki.amigaos.net/wiki/UserDoc:Warp3D
Post Reply