Hardware or software?

Originally posted by mcraighead:
[b]ET3D: Again, it’s not going to happen. You’re massively oversimplifying a very complicated issue.

  • Matt[/b]

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).]

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.

Originally posted by Korval:
[b]"…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).][/b]

Hehe 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.

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.

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.

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.

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.

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).]

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)

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).

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 ) 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 . 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.

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).]

>>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).]

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 - 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.

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.

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!

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.

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.

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.

>>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?