Hello.
I'd like to see a feature in OpenGL, that tells us weather a feature is hardware accelerated or not. If this already exists, then someone please tell me, cos I'm too dumb to find it.
Everytime I have an argument with my work mates about OpenGL vs D3D, they always say in OpenGL you can't find out weather something will fallback to software mode or not.
A little query function to decide this can't be hard can it?
Nutty
I think the problem is that in some cases it's particular combinations of features, rather than individual features, that cause a driver to fall back to software. F'rinstance, a driver might use texture units to implement polygon stipple, so stippling is in hardware if you've got free texture units, and in software if you haven't. Given the ridiculously huge number of possible feature combinations, a simple yes/no query interface isn't practical.
What ought to work, though, is a query function that says "Look, if I draw a triangle right now with all the current state settings, am I going to fall back to software?"
Then the app coder could try various combinations without having to spend several seconds to get a decent benchmark result for each one, or could sort their wish-list feature set in priority order and enable them one at a time until the warning bell goes off.
That's basically right, but there are a number of other practical reasons why this is a bad idea.
It's not going to happen.
- Matt
I will add, D3D doesn't solve this problem, it simply glosses over it, or drops features that can cause these kinds of issues in the first place.
- Matt
Agreed, though people still seem to fall for the D3D hype with monotonous (and depressing) regularity.
Marketdroids. Can't live without 'em. Can't kill 'em.
Out of interest, what are the other practical reasons?
What reasons?Originally posted by mcraighead:
That's basically right, but there are a number of other practical reasons why this is a bad idea.
Frankly, there are some cases when I could know that a feature is not available, but the ICD hide this from me. For example, if I ask for a stencil buffer on NVIDIA hardware in 16 bit mode, I'll get a "hardware" mode, but when I turn on stencil, it will change to software on the fly, which is very annoying. If I ask for a stencil on a Rage Pro card, I just get software rendering, which is what I want to know I'm getting in the first place.
Hello,
this topic seems to regularly appear, as though it was somehow tied to the phases of the moon.
The question you should be asking is not what the opengl card can do you for, but what the system can adequately provide. If you have a 1 bit processor on your zero-percept-compatiable-OpenGeeEll made in taiwan by a manufacturer who has never heard of EssGeeEye, then it is entirely possible that the stencil buffer IS supported in hardware, but that it'd be far better to harness the idle pentium4 on your dual motherboard to do the stencil buffer "in software."
The user and the developer, at the end of the day, aren't interested in what the opengl driver is doing behind your back. No one should be concerned if something is uisng the graphics hardware or not. The ONLY concern that anyone has is: can function X be done fast enough to get the results I want. Whether that falls to h/w or s/w is entirely irrelevent; if its Fast Enough, then that's Good Enough.
<plays seaseme street music> The magic keyword for today is: Abstraction.
cheers,
John
[This message has been edited by john (edited 04-30-2001).]
Well, if you can show me one graphics card with stencil support that renders more slowly than a software implementation on a P4, then you've got a point. But even if you can, what you say is completely irrelevant for the vast majority of hardware. Even three year old graphics cards and current intergrated chipsets are way faster than software rendering. And frankly, the idiot who buys a dual P4 and then makes the great effort to buy a 3D card that will render more slowly than the CPU deserves not to get my support.
As you say, the question is: is it fast enough? In the case of software, the answer is a resounding "NO!" If the hardware is by some chance slower than the software, then tough luck for the user, and he will have to upgrade it. There's just so much I can do. But I do want to know in advance that I'm not using software, since software is never good enough.
Talking of abstraction here is absurd. Users specifically buy hardware that makes rendering faster. If I tell them "this feature can't be enabled because there is no hardware support for it" then they know that they need to change hardware, or, if they know that the hardware should support it, turn to some support forum and ask about it. Given such an error message, people might suggest that they check the colour depth, for example. Without this, users will just know that their program runs very slowly. Finding the reason would be difficult, and they'd be justifiably angry with the developer who didn't care to support their card, and not as justifiably angry with the hardware company who made the "slow card". It will be even more confusing if sometimes the program runs very fast and sometime very slowly (depending on whether stencil is turned on or off).
I want the user to have a good first impression of the program. This means providing the best visual quality while still keeping a good speed (the user will then be able to further tweak the program). To be able to get this balance right, I need to know how quality is traded for speed. While there is no easy way to do this, checking hardware vs. software gives me a good start, by allowing me to disable features that will obviously have a very detrimental effect on speed. If I know that certain features will force software rendering, then I can turn off such features for the card, and perhaps use less visually pleasing ways to render the same thing, or disable some effects altogether.
>> And frankly, the idiot who buys a dual P4 and then makes the great effort to buy a 3D card that will render more slowly than the CPU deserves not to get my support <<
you can actually buy p4 computers with tnt2/m64's
But the TNT2/M64 will still be faster than software rendering.
Posting Permissions
