>> Ove Kaaven <[EMAIL PROTECTED]> writes:
> > 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.
After reading this I looked (instinctively) at your email address. I
got a little scared :-)
You are of course right. If the CPU is going to be busy rasterizing
all of the time, then the interesting stuff is going to suffer. But
I'd have guessed that someone with actual experience coding games
wouldn't have trouble understanding that "is fast" doesn't just mean
"can push 3000 frames per second to the screen", but "fits on a
predefined budget" and that budget has to include things like CPU
usage.
> > 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?
Right, is that a surprise?
> 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).
Right. That's just proper benchmarking.
> > 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.
The game sucks, that's what happens.
> 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.
I never said it was easy to implement with complex applications. Wrt
to reducing geometry, you've got a ton of LOD algorithms to choose
from. The other stuff is eye candy, and it's not that hard to define a
priority list for eye candy (the correct state being "just turn it all
off" ;-)
> 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?
What would be the API for such a thing? "give a function pointer, I'll
tell you how fast that goes"? It's very dependent on the game engine.
A library could provide hints regarding which alternative is faster (in
OpenGL there's usually more than one way to skin cats), but expressing
the kind of thing that would be of real use is hard, how would the
library really know what the game wants to do? You could setup state
and ask the library to measure performance for a predefined set of
operations, but that'd give you a hint, nothing more ("ok, 3D texturing
_is_ dog slow in this setup").
Marcelo
-------------------------------------------------------
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
