is there a way to know if OPENGL uses the soft or the hard rendering ? (ie : are we using the video card or not )
“take a look around” - limp bizkit
its an old question…
but because i’m in good mood:
query the strings to see if its a hardware vendor in. if its microsoft generic driver, then its all in software (same for “MESA” 
)
you can’t get infos what particular part of gl is hardware accelerated and what not, but, as long as you get it fast, you don’t really care… (before t&l no one had hardware-transformations and lighting… no one realised this really)
no way
OF course ppl realised that Dave.
Looking at the vendor string aint enough tho. You can still do 3d textures on GF1+2, yet with the Nvidia renderer, but it’s implemented in software. What ppl really mean is, is this feature an optimal feature of the card, that is can perform quick enough. Unfortunatly there is no way to know that. Apart from making assumptions on current hardware.
I’ve explained previously why a query for this is a bad idea. (Though I have by no means exhausted all of the many, many reasons for rejecting it.)
- Matt
For Win32 apps, I usually query the pixel format after SetPixelFormat with DescribePixelFormat. I use the following to catch software mode:
if ((pfd.dwFlags & PFD_GENERIC_FORMAT) > 0)
{
//report software mode
}
I just report a warning to the status bar so the user knows it is running in software mode.
JWeaver, that only catches software mode fallback, from a non-hardware-supported, pixel format, or due to no proper gfx card drivers installed. It wont detect when a particular feature is using a software implementation in the hardware driver.
I’m aware of your previous statements on this Matt, and theres plenty workarounds anyway, but in an ideal world it would be nice to have some standard way of determining what features a particular piece of hardware can accomplish, without resorting to CPU-super-hog method.
Nutty
well… would be nice if we could close this thread, but we cant…
there is no way, there will not be a way.
it would be nice to query if some feature is fast or not in the implementation (cause you don’t care for hardware, you care for speed), but the only way to query that is to use it, and take the time it took… then choose if its fast enough to use…
you can check if you got a hardwareaccelerated gl-context or not, but thats all.
final state… (once again…)
One of the obvious reasons I forgot to mention before is that in many cases, points, lines, triangles might run in different modes. Bitmap, DrawPixels, CopyPixels can also run in yet different modes. It’s not just a function of the GL state. (For the latter three, the arguments matter too!)
Partial fallbacks are also another good reason…
- Matt
As Davepermen and Nutty was talking about, you really don’t need to know if it’s hardware accelerated. You want to know if it’s fast enough.
Before the newer generation of hardware, transform and lighting, for example, was performed software, and since it was fast enough back then, you didn’t complain.
The best way, in my oppinion, is to let the user choose whether it’s fast enough or not. Make it possible for the user to change some settings, trading quality for performance, or something like that (like you can do in literally all games). If the user thinks it’s fast enough (and trust me, all users defines “fast enough” differently), you have a satisfied user.
Checking the pixel format or vendor string will only test for 100% software opengl. If it is not a generic format, who knows what the vendor implemented in hardware or software. Still it is useful to know if an app falls back to a software implementation (ex: 16-bit color and stencil buffer).
As for speed of individual features, research and testing are the only ways.
Whether or not a feature is in hardware or software is entirely up to the people who write the opengl driver and make the cards. Nvidia could technically sell you a GeForce 4 and then do everything in software inside the driver. That would suck for sure but they aren’t in violation of the opengl spec. I suspect that a lot of new features are usually implemented with a software only path initially and eventually moved to the card. Hardware T&L for example.
Devulon