tor, 07.08.2003 kl. 12.21 skrev Marcelo E. Magallon: > On Tue, Aug 05, 2003 at 12:43:51AM +0200, Ove Kaaven wrote: > > > 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. > > That's a common request of OpenGL programmers and a common > misunderstanding spread by Direct3D programmers (because of > capabilities and the like). Checking the extensions string reported by > the driver you might see GL_EXT_texture3D. Many OpenGL programmers ask > immediately "is that software or hardware?" The correct answer is "who > cares?" What you want to know is if that's fast or not.
That's not always true. Benchmarks aren't everything. Even if the CPU could render slightly faster than the hardware could, that would still unnecessarily tie up the CPU so that less CPU time is available for game physics, AI, sound processing, and such. > With or > without Direct3D-like capabilities, you *have* to code multiple > rendering paths (and this is the misunderstanding spread by Direct3D > programmers, many seem to think that capabilities saves them from this > "redundant" work, which is utter bovine excrement). Don't count me as among those "many", then. "Redundant" work is often more necessary in Direct3D than it is in OpenGL because of these capabilities. And for texture environment in particular, the capabilities aren't very helpful in any case. > The question is > _not_ "does this rendering path run in software or hardware" but "if I > take this path, can I still call this interactive rendering?" And the > only reliable way to do that is to try the path. It's really not that > hard: What if I wanted to port a Direct3D game (of the complexity of, say, GTA3 or MaxPayne) to OpenGL? Since these depend on testing the "validity" of all available paths, I need to understand the engine and start adding specific benchmark code for all of the paths, right? These benchmarks would of course also have to keep the CPU as busy as it could while measuring, to simulate a real gaming situation (this would incidentally also happen to truly detect the software/hardware paths, since this simulated load is likely to always make the software path slower than any hardware one). > for each rendering path > is the path supported? > measure path performance > > select best path according to predefined criteria > > and predefined criteria can be something like: > > * Best absolute performance (you end up with oh,-not-so-feature-rich > paths, but some users want that) > > * The path with the most features which still delivers more than N > fps > > The only question is how to get a reliable measuremnet of the path's > performance. If initialization time is an issue, you can move the path > selection into the loop and use the second criterion (i.e. "if the path > manages more than N fps I'm happy, break") But that wouldn't explain exactly what should be done when less FPS is detected. Should cube mapping be cut out? Can this be fixed by just using a different way to apply the specular light map, or do I have to reduce the geometry? In the main loop, it seems there are too many factors to be able to incrementally calculate the performance profile of the hardware with any reasonable mathematical formula. (As an unrelated aside, these CPU-vs-HW issues remind me of 3DMark03 and the criticism against it - if you haven't heard about it, a 350 MHz PII with a Radeon 9700 Pro outperformed a 2.8 GHz P4 with a Radeon 9600 in 3 of 4 3DMark03 benchmarks, which was not at all representative for what happened when trying to run any actual games on the same hardware.) > Point is, you have to render. No ammount of capabilities and > ValidateDevice non-sense is going to be able to tell you that rendering > large multitextured polygons brings the whole thing to its knees > because the CPU can't send geometry fast enough or because the card > can't rasterize fast enough. Both of those cases have only one reasonable solution - reduce the polygon count, a solution already implemented in various ways in many engines. You didn't mention the only case where "render in a different way" is called for - when the card doesn't rasterize, the CPU does. Besides, the first case you mentioned (the CPU can't send geometry fast enough) already has a solution in NV_vertex_array_range and ARB_vertex_buffer_object. When those are used effectively, pushing geometry to the card fast enough just isn't a problem, as the geometry can be loaded permanently into AGP or video memory where the card can get at it whenever it wants to, it doesn't have to wait for the CPU. I'm interested in a practical solution. Do anyone plan to implement a library that will perform all the measurements you suggest (with the keep-the-cpu-busy addition needed for being useful in practice) and convert them to something similar to D3D-style caps? ------------------------------------------------------- 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
