Hardware or software?

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?

Originally posted by mcraighead:
That’s basically right, but there are a number of other practical reasons why this is a bad idea.

What reasons?

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.

I agree totally with ET3D. As far as cutting edge games are concerned. Software fallback will always be too slow.

The majority of the time on high end cards, your gfx card is waiting for the cpu to keep up, thus implementing someting on a max’d out cpu will drop performance through the floor!

If we can’t have a system that tells us if features are hardware accessible, how about just extensions. And by that I mean the basic premise of the extension, as Matt says it’s all about your configuration. Maybe if a card can support certain features in hardware, at least that would be some help as to know weather to use it on that system. Maybe a little identifier in the extension string or something as simple as that…

for example “GL_EXT_???H" for it’s implemented in hardware, and "GL_EXT???_S” for software.

Just a thought…

Nutty

>>As far as cutting edge games are concerned. Software fallback will always be too slow<<

though i do agree with you guys, ill like to see this feature.

but…
check out the d3d8 vertex shader demo’s, all done on your machine (unless its a geforce3) in software.
they seem to work fast enuf on my CPU (celeron433) to be done in software.
so where does that leave us.

vertex programs (OK software, OK hardware)
pixel shaders (NOT OK software, OK hardware)
stencil (NOT OK software, OK hardware)

I agree that the situation is different regarding vertex calculations. I’m really only talking about rasterization features - they are much much slower in software. Hardware T&L is still not fast enough to make as significant a difference.

Also, note that software T&L integrates seamlessly with hardware rasterization, while a missing rasterization feature forces everything to be done in software. So maybe I should rephrase what I’d like to have - it’s not that I’d like to know if a feature is available in the hardware, but rather whether using it forces rendering to be done completely in software.

>> Talking of abstraction here is absurd.
it is actually very reasonable to talk about abstraction, since that’s the point of OpenGL. actually, it’s very reasonable to talk about abstraction when dealing with almost anything that has to do with computers today (even processors. look at Crusoe. dare i say abstraction?) since we’ll just abstract more and more… at least for some time.

>> I agree totally with ET3D. As far as cutting edge games are concerned. Software fallback will always be too slow.
oh? yeah, that’s true i guess, but the same thing can be said about Voodoo Graphics nowadays. it’s irrelevant of whether or not it is hardware accelerated or not, it’s just too slow.

>> 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).
ok. how about you write a software renderer, do a quick (2 seconds should be more than enough) speed test with some alpha-blended, multitextured triangles (slow in software, fast in hardware) when the program start, and fall back on the software renderer you wrote if the test (= hardware/software acceleration) is too slow for your program? if you want a want fast software renderer, OpenGL is simply not the right way to go.

there is no need to clutter the API with this. it’s bad enough already with all glVertex* style functions etc.

Zed, the reason why the Vertex program demos work fine in software is due to that fact that they are just demos. And dont really chuck about alot of polys. In a full game, you simply would not have enough cpu time to devote to doing your vertex pipelines for 10’s of thousands of vertices.

Maybe it would work for certain objects, but not a whole scene. Unless you had a monstrously fast cpu.

Nutty

Siigron, Opera just caused me to lose the long answer I wrote, so I’ll cut down on the reply to your points (which I did the first time), and tell you how I think this can be done, and why it’s no problem.

I’m not going to try to make you see the value of detecting if rasterization is done in hardware, although I do wonder what kind of application you’re writing where this doesn’t matter, as the difference is huge (even between Voodoo Graphics and software).

As for cluttering OpenGL, I don’t see how this will do it. This is one of the less cluttered features, the way I see it. I can see two implementations that don’t clutter things:

  • Strict WGL: when I ask for a mode, I want to know if there’s a chance it will use software rendering. So, if I ask for a stencil, a mode marked “pure hardware” will give me stencil buffer only if it will implement it in hardware. And this mode will also only give me extensions that don’t cause rasterization to be in software.

  • A flag that I can get with glGet() and says whether the currently enabled set of features will result in software or hardware rendering.

I’m sure you agree that neither of these implementations clutters OpenGL.

It is already possible to detect whether a mode uses the generic Microsoft renderer, an MCD or an ICD. That works fine if I request a stencil on the Rage Pro, since its ICD doesn’t advertise a hardware mode that has a stencil buffer. On a GeForce, it does, even if it doesn’t have a hardware stencil (i.e., in 16 bit mode), and that’s a problem for me. I can see the reason for this - the generic modes are only OpenGL 1.1, so the ICD needs to implement OpenGL 1.2 features in software to be 1.2 compatible.

There is already a WGL extension for mode selection, and I think that adding a “hardware rasterization” flag to it should be easy. The other suggestion is also very easy to implement. These things should be trivial to add, and the question shouldn’t be “why do you need them”, but “is there really a very good reason not to implement them”, considering that they should be so easy to add, and cost nothing in terms of OpenGL complexity.

[This message has been edited by ET3D (edited 05-03-2001).]

"…but there are a number of other practical reasons why this is a bad idea.

It’s not going to happen."

Written by someone who writes NVIDIA’s OpenGL implementation.

“…they should be so easy to add, and cost nothing in terms of OpenGL complexity.”

Written by someone who does not.

End of story.

[This message has been edited by Korval (edited 05-03-2001).]

ET3D: Again, it’s not going to happen. You’re massively oversimplifying a very complicated issue.

  • Matt
  • not supporting dual p4’s with a low end graphics card is naive and childish

  • some graphics cards DO utilise dual processors.

  • when is something accelerated in h/w or not? What if a function is partially based on the driver-end and completed on the h/w end? Is this s/w or h/w? Are you goint to return what percentage of a given function is supported in h/w? How is this expressed if some fucntions are re-enterant, and so the 5% of some functionality in s/w actually consumes 90% of the execution time for some operations?

  • when is something “fast” enough? Do you naively disable feature X just because it doesn’t have “official” h/w support? What if the system can do feature X in s/w fast enough for your application? It is naive to disable feature X on the latest quad-parallel Intel octanium™ just because they have a TNT2 card, even though s/w fall back is plenty fast enough for feature X? (What if you have a 256xMIPS12000 SGI Origin2000. Do you naively fall back to wire frame just because it isn’t an Onyx2000?)

  • what do you return when soemthing is supported in h/w for the frame buffer, but not supported in h/w for pixmaps?

  • ultimately it IS abstraction, since abstraction is (by its very definition) hiding the implementation details.

I don’t understand what is so hard about doing a few rendering tests (take out the SwapBuffer call if you don’t want the user to see it) to see if the state you’re trying to set up is sufficiently fast? This way, you can take into account things that OpenGL implementations don’t know about, like main memory size/speed, processor speed, etc. After all, the graphics card isn’t everything that determines rendering speed.