PDA

View Full Version : Hardware or software?



Nutty
04-13-2001, 12:36 PM
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

MikeC
04-13-2001, 06:44 PM
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.

mcraighead
04-18-2001, 02:20 PM
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

mcraighead
04-18-2001, 02:21 PM
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

MikeC
04-20-2001, 02:06 PM
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?

ET3D
04-30-2001, 01:29 AM
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.

john
04-30-2001, 03:56 PM
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).]

ET3D
05-01-2001, 10:00 AM
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.

zed
05-01-2001, 08:58 PM
>> 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 http://www.opengl.org/discussion_boards/ubb/smile.gif

ET3D
05-02-2001, 02:46 AM
But the TNT2/M64 will still be faster than software rendering.

Nutty
05-02-2001, 04:08 AM
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

zed
05-02-2001, 04:52 PM
>>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)

ET3D
05-03-2001, 01:18 AM
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.

Siigron
05-03-2001, 02:51 AM
>> 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.

Nutty
05-03-2001, 03:54 AM
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

ET3D
05-03-2001, 01:32 PM
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).]

Korval
05-03-2001, 03:30 PM
"...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).]

mcraighead
05-03-2001, 04:29 PM
ET3D: Again, it's not going to happen. You're massively oversimplifying a very complicated issue.

- Matt

john
05-03-2001, 05:00 PM
- 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(tm) 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.

Korval
05-03-2001, 11:02 PM
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.

ET3D
05-04-2001, 02:20 AM
Originally posted by mcraighead:
ET3D: Again, it's not going to happen. You're massively oversimplifying a very complicated issue.

- Matt

Matt, maybe I am, but I'd appreciate if you could explain this. I hate taking such claims at face values.

As I see it, the ICD must know if it's going to use software rasterization with the currently enabled features. Otherwise, how does the software rasterization engine gets called? So why can't I just tap into that test, and know whether software rasterization is taking place or not?

Please let me know what's wrong with this assumption.


[BTW, apologies MikeC - I'm basically repeating your idea.]

Regarding the selection of modes, I realize that it's impossible to guarantee that a mode won't use software, but it should still be possible for the ICD to tell me that a mode WILL use software if the features requested are used (such as stencil or accumulation buffer).


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

ET3D
05-04-2001, 02:51 AM
Originally posted by john:
- not supporting dual p4's with a low end graphics card is naive and childish


Why? Most programs (I'm mainly talking games here) don't support low end graphics cards, period. And I don't mean something like a TNT2 M64, but a Trio3D or Rage IIC. A dual P4 with such a card is a far fetched idea, and is likely to be so rare that it's not worth addressing.

Same goes for your other scenarios. I'm addressing a PC. The graphics card speed in this market is growing A LOT faster than the CPU speed, so the benefit of hardware rendering over software rendering only becomes greater with time.

ET3D
05-04-2001, 03:41 AM
Originally posted by Korval:
"...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).]

Hehe http://www.opengl.org/discussion_boards/ubb/smile.gif But as a software developer, I remember myself telling people "can't be done; not a good idea" on more than one occasion, and even coming up with some pretty good excuses. This didn't mean that this was really impossible, and I sometimes even implemented a solution after a re-think, and convinced people why it was such a good idea. Here I didn't even get the excuses.

About benchmarking - I'll probably do that eventually, too, to some extent. But as both Matt and Mike pointed out, there can be quite a few combinations of features that can cause software rendering, and there's a lot of hardware out there. Not only will a feature for detecting software rendering help my development process, but it will also enable me to provide the user of some card I didn't test with a way to send me information about the state of the program, in case he gets suspiciously low FPS.

Dodger
05-04-2001, 04:27 AM
Would there be a possibility to implement it as an error message? Fallback into software when certain feature combinations are ued could produce an error that could be retrieved by glGetError... ?
Just an idea, cause it would fit into the pipeline and also solve the problem that only certain feature combinations cause a software fallback - I'm not sure how it fits into the specification of what an 'error' actually is supposed to be though.

Bob
05-05-2001, 05:30 AM
You mean we should treat the software renderer as an error? I wouldn't think that's very clever. Error is when you do something wrong, for example, passing invalid arguments. Falling back to software is most certainly not an error, it's a limitation of the hardware.

ET3D
05-05-2001, 05:59 AM
I agree with Bob, although I can understand what Dodger is saying. It could help performance debugging if the ICD had a debug mode that asserted that hardware rendering was used. If the program stops because of an assert when software rendering, it will be easier to find that it happened, and why.

But it will still be nice to trap software rendering before actual rendering, and, when possible, even before context creation.

ET3D
05-09-2001, 10:50 AM
In the past few days, there have been a few messages in the advanced OpenGL forum where people complained about slow rendering, and would have benefitted greatly from knowing that it was because of software rendering.

Providing a solution for this, even if not complete and 100% guaranteed, would be very helpful.

GT5
05-16-2001, 04:32 PM
has it ever occurred to you that even running animating simple polygons using software implementation is very very slow (1-2 FPS) compared to hardware acceleration?
You guys might say, well, the CPU is doing all the work. Fine... but! back in the early days of graphics programming when game programmers used DOS to code their games, there was no such thing as OpenGL or DirectX. The games ran fast even on a crappy (well those days it was the best) 486Sx computers with 16MB RAm and maybe 1MB of video card.
How did they manage to speed up FPS in those days? You might say they used backface culling, etc, etc BUT backface culling is still implemented in OpenGL software mode right?

Sorry, but I don't quite understand why these days running an animation in software mode is alot slower than those days when they did it in DOS (or even in Windows!)...

[This message has been edited by GT5 (edited 05-16-2001).]

Sheepie
05-16-2001, 07:36 PM
Here! Here! GT5!

There seems to be a growing belief that hardware will solve all of our problems and that software is passe. Last time I checked, your hardware still needs software to function. How about this. We take all of you that don't think software optimization is worthwhile and who *claim* to know how to optimize Assembly(you know who you are), and sit you in front of an old 386 running Windows 3.1 and have you all program Doom. My guess is that you would be looking for a graphics card, then you'd find out what real optimizing was all about.

And to think ET3D called optimizing assembly - thoughtless. Let's see your best BTC opcode replacement(btw, it's not a graphics function so your G2 won't help you)

john
05-16-2001, 08:17 PM
function. How about this. We take all of you that don't think software optimization is worthwhile and who *claim* to know how to optimize Assembly(you know who you are), and

there is a difference between clever algorithm optimisation (which IS worthwhile) and optimising instruction streams (whose important is diminished on modern computers).

Olive
05-16-2001, 11:32 PM
There seems to be two discussions going on here. By the way, all I'm discussing here for professional application (games, whatever) development.

The first one is: It'd be interesting to know if OpenGL falls back to software rendering for a given mode. Why ? Because then I can use an alternative solution. Be it my own software solution or another mode. But then, as someone already said, the question is really not "am I hitting a software path" but more "Is my refresh rate to slow?". In which case why not make a small benchmark that measures all the possible modes in the app and use that to configure your engine? Let the user do the benchmark an output a log file that your app will use to configure itself. Imagine that: you bought a nice killer app, you run your benchmark and you get the nice and comforting feeling that the app will somehow take all the juice and money out of your hardware (CPU, motherboard, memory, GPU, everything!!!). And if you happen to change driver versions, CPU, etc. just run the benchmark again! Wow!

Second discussion: The OpenGL software path is too slow but some here claim that, with good optimisations (assembly or algorithmic, and I won't say which one I prefer http://www.opengl.org/discussion_boards/ubb/smile.gif) software rendering can be fast/faster. Then shouldn't we (users of OpenGL) ask that the default OpenGL software renderer (Microsoft's if I'm right) be maintained in the same way as our adored video card manufacturers maintain their drivers? Put some effort in making it faster! Ok, this is naive...

Finally, as a conclusion to this post, I'd like to give my opinion about this war between "hard-assembly" optimizers and "algorithmic-design" optimizers (which I think this thread is about). It's a recurrent debate in the computer science world. I'm more of the second type, by the way. The question is really more of an economic/time one. You usually spend more time/money optimizing your code at a really low level for a given speed gain than you would if you redesigned your system or changed your algorithm. Ok, ok. We know sometimes the question is just optimizing the best algorithm there is. But... do the clients really wan't this small speed gain? I'm not talking about the hardcore hardware lover gamer who definitely seems to judge a game by its three digit frame rate http://www.opengl.org/discussion_boards/ubb/smile.gif. I'm talking of the general software audience and most importantly, the left out public. I think its far more important for the computer industry to spend time designing layered APIs and components, and especially on the interfaces (which is all what this forum is about!!) or an the content of the software (for games) then spend time on optimizing to the max one particular feature of a particular application. I know its hard to drop this low level optimisation thinking because we all want to have the most out of our hardware for the price it costs. But look at the electronic industry. All the industry is made up of components and we all know (and the industry does) that a computer would be much much faster if it was integrated in one single chip. But it would take more effort in design to make that chip. I'm just talking of the effort in designing the chip because we all know that building a chip doesn't cost much when built in large quantities. Software isn't manufactured, hardware is so lets stick to the common part: the design. Thanks to this component design, civilisation has gained a lot more (ok, I'm a bit enthusiastic... Part of the world has gained from it).
I think that the software industry should start (and it has) working a lot more like this and not spend more time on trying to rebuild something that others already have or concentrate on assembling those bricks to make more novative applications. As someone said, (approximate quoting) "I stand on the shoulders of giants".

Ok. Finished. A bit of a disgression at the end. Sorry about that. Over.

Nutty
05-17-2001, 12:17 AM
Sorry, but I don't quite understand why these days running an animation in software mode is alot slower than those days when they did it in DOS (or even in Windows!)


I'll tell you why it's alot slower, Resolution and color depth. Ever tried writing a true-color DOS app. Takes bloody ages to write all them values. In the olden days of DOS, 640x480 was like maximum res too. These days people use resolutions of 1600x1200.

Also I'm not talking about animations. You dont really need that much of OpenGL to do animations. I'm primarily concerned with games, and games with frame rates under 30fps in my opinion is too slow! Trust me if you're writing a full game for the PC, and part of the render fell back to software implementation, when you expected it to be done via the graphics hardware, you'd sure know about it, cos you're frame rate would fall through the floor!

As far as software optimization goes, it's all well and good in the right place, but to be frank, your shiny fast hand tuned code on a 1.5GHZ P4, just aint gonna cut ****, when it comes to rendering millions of light shaded, multi textured polygons, with anti-aliasing, and all the other stuff that consumers demand from games these days.



Then shouldn't we (users of OpenGL) ask that the default OpenGL software renderer (Microsoft's if I'm right) be maintained in the same way as our adored video card manufacturers maintain their drivers?


You can ask, but they wont take one bit of notice from you! Simple as that. Their response would be "Use Direct X instead"

The fact is, software fallback aint gonna cut it, no matter how many hardcore assembly optimizers you stick into optimizing the software fallback code. The reason for this, is becuase you dont have the available CPU time to use on graphics rendering. It would probably take up twice as much CPU time as the rest of the game engine, which just isn't acceptable, or even available.

Nutty


[This message has been edited by Nutty (edited 05-17-2001).]

Bob
05-17-2001, 12:45 AM
>>Then shouldn't we (users of OpenGL) ask that the default OpenGL software renderer (Microsoft's if I'm right) be maintained in the same way as our adored video card manufacturers maintain their drivers?

Currect me if I'm wrong in this one, cause I'm not 100% sure.

When you enable a certain feature that causes the driver to fall back on software rendering, it's no the OpenGL implementation from MS that kicks in, it's the software renderer from the hardware manufacturer. This is how I understand it. If I, on my GeForce2, enable a feature that my GeForce can't handle, it will be NVIDIA's software renderer that kicks in, not MS's, as it seems like you think. Improving MS's implementation won't help then. Won't this easily be checked by calling glGetString(GL_RENDERER) during runtime. As far as I remember, this string, nor any other, won't contain "Microsoft" (or whatever it is) once the hardrware driver is initialized, even though you are using a software renderer.

So, if you want a faster software renderer to fall back on, you need to ask the hardware manufactureres to provide one, because opengl32.dll is just passing every call to OpenGL to the driver, and it does not know wether we are performing software or hardware rendering.

Now, just think what could be done IF MS's driver knew about sw/hw and where to take over. Just enable the features you want to test, draw a triangle and see if glGetString(GL_RENDERER) (or GL_VENDOR or whatever) says it's MS's generic driver. Then the whole problem with sw/hw-querying would be solved, right?

[This message has been edited by Bob (edited 05-17-2001).]

ET3D
05-17-2001, 07:18 AM
GT5, I'll answer you before making another post that will hopefully get this disussion back on track. Were those DOS games able to run if you had a CGA card, or a 286, or just 1MB? You talk about 16MB as if it was little. Most 486sx computers had 4MB at best! And even if you had a high end system, you were lucky to get 20 fps in a game (and you felt it was really smooth). I'm not even mentioning sound blaster compatibility and other such issues. The situation today is not any worse, and if anything it's better, IMO. Not addressing people who don't have hardware acceleration is the same as not having addressed CGA or EGA then. It's an older standard that's passing from the world.

My rule of thumb would be (and I just invented it http://www.opengl.org/discussion_boards/ubb/smile.gif - the minimal spec would be what was a mid-range system 2 years ago, or high-end 3 years ago. The software is not guaranteed to run well on it, but it should run. I'll want to make sure that when it's released, the software will run decently on the low end systems available then, on what was mid-range hardware a year before, and high end 2 years before. This gives high end hardware a 3 year or so useful life span, which I think is reasonable. For a developer who's working on software that will appear in a year, this means making sure it works well on current mid-range hardware (1GHz CPU, GeForce2 MX), which will be low end when the software appears, making sure that current low end and last year's mid-range (TNT, i810) can run the software, and taking advantage of high-end hardware (GeForce3) that will be mid-range when the software appears.

ET3D
05-17-2001, 07:19 AM
I think that it'll be better to sum things up from my POV, to get the argument on track (even though I just wrote a few paragraphs about why benchmarking isn't the greatest solution, and it's a pity to throw them away). I'll sum up my argument with these two claims: 1) it is useful to distinguish hardware from software rendering; 2) being able to do this via the API is very convenient.

The argument I've seen against (1) is that hardware could be slow, too, and it's the speed that matters, not the implementation. To which my reply is that: a) 3D hardware is faster than software on the vast majority of current machines, and the speed difference is constantly growing; b) it's important to know whether the slowness if because there's need for better hardware, or because the hardware isn't being taken advantage of.

The argument against (2) is that it's possible to do in other ways (i.e., a benchmark). My answer is that using the API is more convenient and faster (for debugging, in particular). I also argue that API detection of software rendering is not inferior to benchmarking. Therefore (as a result of these two claims) it is a better solution.

The last argument against hardware/software detection via the API is that it's difficult or impossible to implement. As Matt said, there are issues I and others who are for this are not considering. There is little I can do to refute this, because he doesn't tell me what issues these are. This is a moot point, as we can't convince each other without getting into details. This is bad for me, since I'm not making the shots here. All I can do is maintain that if it _is_ possible to implement, then it is worthwhile to have it.

GT5
05-17-2001, 02:27 PM
I'll tell you why it's alot slower, Resolution and color depth. Ever tried writing a true-color DOS app. Takes bloody ages to write all them values. In the olden days of DOS, 640x480 was like maximum res too. These days people use resolutions of 1600x1200.

I partly agree with you. Sure, the higher the color depth, the more data you will have to write, but those people who have used vesa 2.0 and dos-extended mode to make games know that it is still possible to still achieve greater than 30FPS.
Why isn't it the same for OpenGL in software mode? I think this windows interface is causing all these problems.


So, if you want a faster software renderer to fall back on, you need to ask the hardware manufactureres to provide one, because opengl32.dll is just passing every call to OpenGL to the driver, and it does not know wether we are performing software or hardware rendering.

Well... opengl32.dll DOES know when hardware mode or software mode is possible so why not have a GL command which returns TRUE or FALSE if it can be done in hardware mode?


GT5, I'll answer you before making another post that will hopefully get this disussion back on track. Were those DOS games able to run if you had a CGA card, or a 286, or just 1MB? You talk about 16MB as if it was little. Most 486sx computers had 4MB at best!

I do remember I was playing DOOM1 and this other First Person Shooter game that only required 4MB of memory! But I had a 486 back then with 1MB of video mem and 4MB of main mem. It was still possible using a standard VGA card.

If I remember correctly, even MK3 was running smoothly on my 486 computer but I think that game required 8MB not 4MB.
Anyway, main memory is not the issue here, these days we have at least 128MB of memory installed in our computers, with fast video cards, yet in OpenGL software mode it is DEAD SLOW!

ET3D
05-17-2001, 02:45 PM
Anyway, main memory is not the issue here, these days we have at least 128MB of memory installed in our computers, with fast video cards, yet in OpenGL software mode it is DEAD SLOW!

True. But there are two answer to this. First, if everyone has fast video cards, why invest time in optimising software mode? That I think is the main reason, and will only become more true. That's a major reason distinguishing between hardware and software modes simply would be helpful.

The second reason is that OpenGL needs to conform to strict rendering rules. This prevents some forms of optimisation from being applied. While it should still be possible to make OpenGL faster than the current implementations, it would be even faster if you write a software renderer that isn't OpenGL. It could even have the exact same interface, but it won't be OpenGL if it doesn't follow OpenGL rules. Which is why I said somewhere else that if I wanted to support software rendering I'd program or buy a software engine - it'd surely be faster (assuming that it's decently written) than any software OpenGL, even a heavily optimised one.

GT5
05-17-2001, 03:21 PM
First, if everyone has fast video cards, why invest time in optimising software mode?
Because some of the features are not supported in hardware on some video cards!
I have a nVidia TNT1 which is still fast for some applications but as soon as I use a feature which is not supported (such as cube mapping, bump mapping, stencil buffer in 16-bit) it is very slow.

ET3D
05-18-2001, 01:20 AM
This is exactly what started this thread, and the reason I'm for a simple way of detecting hardware vs. software rendering.

I think that it doesn't make much sense for a chip maker to dedicate a lot of work to optimising a software implementation. Much better that they'd work on making the hardware part of their drivers fast and robust. As I mentioned before, it's also more difficult to optimise this, since the hardware rendering and software rendering should look the same, and be able to blend seamlessly.

As I see it, the software implementation is provided for two reasons: completeness and to allow developers to experiment with advanced features on low end hardware. By completeness I mean that there's a basic set of features (like stencil) that OpenGL must provide, and therefore must be made available.

As a developer, I want my software to be able to check whether using certain features gets me software rendering, and use this to adapt rendering so that features that cause software rendering in that particular mode aren't used (and for debugging, I'd like to know that the slowness is due to software rendering). A lot of effects can be done in different ways (perhaps not as good) on hardware that supports fewer features, and I'd rather use these methods than have an optimised software implementation rendering advanced features, since that'd be still too slow.

Bob
05-18-2001, 01:22 AM
>>Well... opengl32.dll DOES know when hardware mode or software mode is possible so why not have a GL command which returns TRUE or FALSE if it can be done in hardware mode?

Software MODE, are you refering to the PFD_GENERIC_ACCELERATED-thingie when creating the pixelformat? If so, thats not what I'm talking about. Yes, opengl32.dll knows when the driver is able to do the rendering, or if opengl32.dll is supposed to do it. But isn't this choise made only when creating the pixelformat? Consider this: I create my window as usual, and get hardware acceleration. Then, on my GeForce, I start using 3D textures which is not supported in hardware. Then, does opengl32.dll knows my driver is falling back to software rendering? It certainly don't take over the rendering itself, because opengl32.dll today does not support 3D texturing at all. How can opengl32.dll determine wether my hardware specific driver is letting the hardware do the job, or doing it itself?

Siigron
05-18-2001, 01:44 AM
The main reason software mode is slow is because of bilinear filtering. It is slooow to do that in software. Gee, wonder why no old DOS games used bilinear filtering? :P
Microsoft's software renderer sucks, both Mesa3D and SGI's software renderer are faster. But, once again, software rendering is dying. It might be revived in a few years when we have "extremely fast" (compared to now) processors, but we're not there yet.
Besides, Quake ran at 17 FPS on my old Pentium 75, Quake3 runs at over 60 FPS on my P3 700 so i don't know what you're talking about WRT slow animations compared to the DOS days.

GT5
05-20-2001, 03:12 PM
Software MODE, are you refering to the PFD_GENERIC_ACCELERATED-thingie when creating the pixelformat?
No, thats not what I'm talking about.

Then, on my GeForce, I start using 3D textures which is not supported in hardware.
THat's what I'm talking about, that is, in while running in accelerated mode, you choose something which is not supported by your card. Software mode kicks in, and so opengl32.dll determines that we should use software mode because that feature in hardware is not implemented.

Bob
05-20-2001, 10:45 PM
So, it's opengl32.dll that determines wether the driver is supposed to do software or hardware rendering? Somehow it has to know about it. How? If opengl32.dll knows about it and is able to tell the driver, why can't it tell us aswell? Sorry for this somewhat off topic discussion here, but I find it hard to believe it is opengl32.dll that tells the driver what to do internally.

ET3D
05-21-2001, 10:57 AM
I'm pretty sure that it's not OpenGL32.dll that determines this, but the ICD. OpenGL32.dll just works as an interface to the ICD, when rendering through the ICD. I still think that the ICD should know when it's rendering in software, and be able to return this to us - even though it may not be trivial to define what "software rendering" consists of. However, Matt says that there are other reasons why it's a bad idea. I wish I knew what...