man, 04.08.2003 kl. 22.38 skrev Ian Romanick:
First, let me point out that taking that type of a tone with open-source developers is likely do nothing but get you ignored.
Since linux kernel developers seem to have no problems with using any kind of "tone", I was expecting a relatively moderate tone like mine to be pretty unremarkable among open-source developers. Then again, I suppose it could be argued that kernel developers are free-software developers, not open-source developers, in which case I'll try to be more careful.
Different strokes for different folks. That's all I'm saying. :)
[snip]
Third, the "vendor/renderer strings" word-around is a completely different issue. To the best of my knowledge, that was not an issue of performace. That was an issue of certain hardware not implementing certian functionality (i.e., certain blend modes) correctly. That some hardware can't be made to follow the spec is unfortunate, but it is not something that an additional API should be created to work-around. That basically degrades the standard from a set of rules to a set of vague guidelines. Non-graphics APIs don't do this, and neither should a graphics API.
If I understand right, those drivers did not follow the spec exactly, simply because following it exactly would require a software fallback, which would probably be... slow, something not desired for some reason. Now here's a thought - implement the driver correctly, let apps detect that this particular configuration is slow, and then let apps configure the more limited but fast texture environment instead if it works for them.
Then the standard is once again a set of unbreakable rules. Nobody loses.
I agree. That's not the choice that they made at the time. There's nothing we can do about it now.
[snip]
Either it needs a constant color of 0x00ffff00 or it doesn't.
If you mean the app, then this is a naive view. In most cases, the engine may not *need* such a constant color, it can work fine without it, it'll just disable the particular effect that needs it, or replace it with a less realistic and less demanding one, or just a more compatible multipass technique, as software fallbacks are still worse. But it'd still be nice for the engine to know when this constant color does *not* cause a software fallback, so that the more demanding technique can be used if the user upgrades his card.
I think you've missed the point here, which is my fault. I gave an example of the core problem instead of stating it. The problem is that there is a countably infinite number of reasons why a fallback could happen. No driver developer (closed-source or open-source, Windows or Linux) is going to put a rich interface in their driver to explain why a fallback happened. Even if they did, no application developer (at least not any that have deadlines to meet) will code to test the myriad possible reasons. Nobody has time for that in their schedules.
I don't buy this argument. ValidateDevice doesn't do a lot of explaining either. The interface it presents is not hard to implement. I'm only asking for knowing at runtime that with the current environment, a fallback kicks in. *Why* it kicks in is secondary and can be checked at development time with the debugging techniques you already mentioned, but when the game is finished and deployed, only *whether* the fallback kicks in really matter.
On the usage side, game developers also only have a finite number of texture environment techniques they try to validate, then they use the best one that works. (And in OpenGL, if the apps don't care for max speed, they don't have to check, they can just let the software fallback kick in, right?)
May I ask a question here? Could you provide some more details on what exactly ValidateDevice does? From your statements here and later in this message, I think that it may do much less than I thought it did. Does it just validate a given texture environment setting? If so, that changes things somewhat.
Pretty much everything that I've said in this thread so far and in the remainder of this message is based on the assumption that ValidateDevice answers the general question, "Can the hardware handle this *complete* set of state in hardware?"
In either case, I can envision scenarios, especially on hardware like the G400, where it could say "Yes" when the answer is really "No" and vice-versa.
[snip]
That's the problem, and that's why nobody implemented anything. At best the cap bits or fallback flags are a hint, and at worst they are an outright lie.
If you really wanted to avoid that, you could define the query to say "fast-path" and "slow-path", instead of "hardware" and "software".
That's been the problem in creating something like this before. "Fast" and "slow" are completely subjective.
Instead, we've spent our time improving the performance of our drivers and improving the ways that applications can measure their frame rate. Many of the open-source drivers support GLX_MESA_swap_frame_usage (basically a GLX version of WGL_I3D_swap_frame_usage), which can be useful for measuring performance.
Okay. So instead of pulling out your fingernails by calling setting up some environments and calling ValidateDevice a couple of times, you have to actually make your game's initialization routine *profile* all the texturing techniques on startup by drawing some rotating gears or something textured in various ways and see which one gives the best FPS. Neat idea, and probably useful in its own right, but I'm not sure that programming such an initialization routine isn't going to take anything off anybody's game development schedule, or get any users to complain about the long game startup.
That would be one way to use it, but it's certainly not the recommended way. I was under the impression that Max Payne, for example, would dynamically adjust its rendering parameters while the game was running to maintain some target frame rate. {MESA,I3D}_swap_frame_usage are intended to be used to calculate how much of your target render time was used. If there was a lot left, increase the details. If you went over budget, decrease. One variable that could be tuned (by the application) is the texture environment used. If one setting gives 5fps, try a different path. :)
The intention isn't to make decisions in advance. In a lot of cases that's a silly thing to do because the load will change a lot. The intention is to make decisions on-the-fly. The hardware may be perfectly capable of DOT3 bumpmapping. When there's a lot on the screen it might bog things down too much, so switch to different method, disable bumpmapping altogether, etc.
Just look at GTA3 to see how important this is - it does not have *any* 3D options whatsoever - it's designed to Just Work on the user's system, autodetecting its capabilities and tuning itself to it. And Direct3D lets it - why can't OpenGL implementations be as end-user-friendly? Can Linux really win on the desktop if 3D games can't be made this simple?
Here's something else for you to think about. All of those companies that make D3D drivers also make GL drivers. Don't you think that if ISVs (i.e., their customers!) really needed this type of functionality that at least one of them would have made an EXT or vendor specific extension to provide it? Yet, none of them have. Ever.
And what's the correlation between ISVs that use OpenGL for various solutions, and PC game developers that target a wide range of end-user hardware (and thus spend a lot of resources making it work great on all of it)?
You'd have to ask Nvidia and/or ATI. :)
I'd really like to hear something more technical than this "this is not needed" rhetoric.
I don't think anybody has ever said "this is not needed." What has been said, with concrete examples of why, is "this is an intractable problem in the general case." It may turn out the ValidateDevice is more limited in scope than the general case.
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
