tir, 05.08.2003 kl. 01.43 skrev Ian Romanick: > Different strokes for different folks. That's all I'm saying. :)
Will keep that in mind, then. > 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. Yeah, I guess I should have explained that, since the name may be a little bit misleading. ValidateDevice is texturing-only. (All other hardware features and misfeatures are exposed via device capability flags.) The Direct3D 9 version is currently documented at http://msdn.microsoft.com/library/en-us/directx9_c/directx/graphics/reference/d3d/interfaces/idirect3ddevice9/validatedevice.asp?frame=true > 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. Do you have an example? Or is it with stuff like stippling and such? > >>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. Well, perhaps. But for the example you used, drivers that always run TCL and vertex shaders on the CPU, it would probably just return fast-path always... but I think in general hw-accelerated should be fast-path, considering that the cpu should preferably be considered busy enough with game simulation or similar non-rendering stuff (and apps that aren't that busy won't care). But I suppose that yes, opinions may differ. > >>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. :) Maybe, but wouldn't that create an uneven framerate as the renderer keeps flipping in and out of software paths? I'd think for the most part, dynamic detail level is there to adjust the geometry detail, not the texturing technique; it's going to be rather hard to isolate texture-rendering slowness from high-geometry slowness for dynamic detail, I think. > 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. Having information in advance would certainly make it easier to know that the method it's switching to won't be even slower, and what exactly the slowdown is (geometry, the environment-mapping, or maybe just some odd GL_MODULATE that the hw doesn't support). > >>>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. :) Most games seem to be Direct3D, not OpenGL, to me. There are exceptions, of course; for example, some games (like Warcraft 3 and Monkey Island 4) do have an OpenGL rendering mode, but it seems it's mostly to be portable to Mac. On Windows, these engines use Direct3D. It's interesting that a game that has an OpenGL backend still prefer to use Direct3D where available. One could speculate about the reasons, but *some* inadequacy of OpenGL seems likely. And then there's id software. Sadly, they are the exception, not the rule. > > 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." I'm aware of that, even Direct3D does not really solve that very well, so I tried to put the focus on texture environment only in my initial posting. Perhaps not obviously enough, since I didn't want to exclude interesting comment on non-texture-environment issues (and it would have been cool to know if e.g. stenciling is hw-accelerated or not), but since pretty almost anything non-texture-related is just "the hw supports this or it doesn't, no driver improvements can fix that", the vendor/renderer table solution would be less problematic here. ------------------------------------------------------- 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
