PC still playing Amiga catchup

[Daedalus]

Never heard of OpenCL

http://en.wikipedia.org/wiki/OpenCL

[amigaksi]

From GPU's POV, maintaining a CPU style legacy may not be efficient for the transistor budget. For example, GPU's allocates their transistor budgets to math units.

Also, I don't think NVIDIA would share thier GPU ISAs with anyone else.
...

Actually, even VGA standard bandwidth and chipsets varied but they used the same I/O ports and memory map areas.  I have timed various VGA graphics cards using standard graphics modes (these are older PCI cards) and the Matrox had one of the highest bandwidths (> 2X over ATI), but they were accessed the same way.

>Close sourced NVIDIA and ATI driver packages include JIT re-complier engine. You are welcome to write Radeon drivers that would beat the offical Radeon drivers.

Even amongst Radeon cards, they don't use the same I/O ports.  

>AMD and NVIDIA offers "close-to-metal" with thier GPUs, but they are vendor specfic. With PS3, NVIDIA provides LibCGM thin-layer.

It's "thin-layer" may be worth it if it's not vendor specific.

>Pre-programmed macros on MS gaming mouse while playing with Xbox 360 players in Gears Of War(via Xbox Live) is an advantage.

>I use an 8 button gaming mouse e.g. able to change sensitivity on-the-fly (two buttons), change weapons, use alternate weapons fire, use health packs and 'etc'.

I still find the simple one/two button-based games fun and easy.  I played this 3D game on playstation where you had to pick up objects but the interface is highly complicated and you miss the object many times and when you are under attack, you have to first set position then move or press one of the buttons to attack back.  By the time you figure it all out, game's over.

[jkirk]

Did I start this? Or were they already at each other throats? :griping:

Interesting read anyway.

lol no this has been going on on a couple threads.

[bloodline]

Never heard of OpenCL-- but OpenGL is also an API standard.  I think the problem with VGA cards occurred when no hardware standard was set for going past it's basic 640*480*16/320*200*256.  People started writing their own methods of doing 640*480*65536, 1024*768*16777216, etc.  

Some important points here:

Even at that point, it wasn't that bad since you could set the mode via VESA BIOS and still go directly to A000:0000 and use the I/O ports for palettes.

The BIOS is a software API... the very thing you are arguing against... in fact it was the fact that the BIOS abstracted the hardware that lead to the popularity of CP/M (the forerunner of MSDOS).

But then it got worse and worse as more and more features got added by various vendors.

And this is why we use APIs!!! Ok, so you have now successfully argued against yourself, maybe you understand

[jkirk]

Take an easy example of trying to use more than 256K of VGA memory.  Each VGA card implemented its own I/O Window register like $3D4 or $3CE.  There are hundreds of different I/O Window registers some using 4K banks some 64K banks and then there are various methods of using the linear memory mode at various memory mapped locations.  Now all this could be a single Window register and single linear memory area if things were standard like they were for the basic VGA card (A000:0000, $3C0..$3DF, etc.).

they are standard. standard through the api. this way you create a program and the os retains control over the hardware. after all it is an Operating System. not window dressing for direct hardware access.

i am not going to say that the api system couldn't be implemented better. what i am saying is this method is fine and is not a problem.

[alexatkin]

On the contrary, when Creative had to go from ISA sound cards to PCI ones they had a HELLOVA time making them backwards compatible.  There is also an endless list of "soundblaster emulation" cards which never worked right as because they were "hardware compatible" they couldnt fix it.  However if you use a higher level API and software drivers you can easily patch any compatibility problems later.

My god, I was upgrading in that era when they went from ISA to PCI for sound cards, half the time games wouldn't work properly.  Oh and lets not forget, soundblaster emulation on PCI sound cards is done in SOFTWARE, at least partially.  I believe its something to do with having to emulate the ISA chipset timings which is also why it did not work properly.

The switch to Direct X brilliant as you very very rarely get this sort of problem anymore, it just works.  Kinda breaks your whole argument that backwards compatibility is easy.

Now when talking graphics cards things get even worse as they are so much more complicated.  Do you REALLY think its cost effective to include legacy modes in every single new card you release?  

As for VESA, as I understand it that is still an API but it was mostly supported via the graphics card BIOS which is the only real difference between hardware and software support anyway.  That said, DOS games would always come with software VESA as many graphics cards lacked support, or supported the wrong specification.  So the whole VESA introduction could just have easily been done with software drivers anyway except as people were using DOS (Win95 was not yet a large enough install base to support exclusively) it was easier to keep it in the graphics card BIOS.  The instant enough people were using Win95 over pure DOS though they made the jump, as it was so much easier to support.  If keeping things in hardware was as good as you say, why was it so hard to get DOS games working properly compared to once they made the jump to Windows?
The overhead can't be that bad either as games still improved when we jumped to Windows instead of DOS, despite the fact by your argument the extra power in the PC should have been stolen in API inefficiencies.

And blimey, how large do you think the graphics card BIOS would need to be in order to have backwards compatibility for ALL GPU functions?  How often would it need to be patched to fix bugs?  Quite frankly, its just not practical and you damn well know it.  Using VESA as an argument just seems plain silly, given the above that early VESA was supported via software drivers - very much like how modern drivers support Direct3D today.

Nobody is saying that 100% accurate backwards compatibility would be a bad thing.  I'm sure there are a few benefits from a developers point of view (for a few very rare unusual applications), but you have to live in reality.  There is no PC standard which says your sound/graphics card must talk in this language (apart from VESA and old VGA standards), with these memory addresses, etc.  There is also the little thing of evolution to think of.  If you write a strict standard you are stuck with it, forever.  However with an API if you find more efficient ways of doing stuff at the hardware level, the only restriction is rewriting the software driver.  This is not a whole lot different to how it works at the hardware level except the risk/cost of doing it hardware level is insane (hard to fix once in production, huge BIOS to handle the translation).  And no, directly pushing bits around the GPU directly is simply insanity.  It was fine for Amiga because the chipset was relatively simple, but a modern graphics card GPU is going to be many times more complex than a whole Amiga so claiming that you should have the same hardware access is just plain silly.

Likewise when two competing companies make a graphics card with new functions, how on earth do you propose they would make them compatible with each other without an API?  You can't develop the standard that far in advance of the actual hardware development because you are keeping your cards close to your chest to beat the competition to market with the latest features.

Again, of course a hardware level API like VESA is handy if you want to bang the hardware more directly and save yourself some CPU cycles.  However nobody outside of an insane asylum is going to want that level of control.  Nobody actually NEEDS that level of control.

[amigaksi]

they are standard. standard through the api. this way you create a program and the os retains control over the hardware. after all it is an Operating System. not window dressing for direct hardware access.

i am not going to say that the api system couldn't be implemented better. what i am saying is this method is fine and is not a problem.

OS does retain control of the hardware but it application can also use it directly-- the way it's set up in Amiga.  APIs will always be worse than direct control from efficiency point of view and knowing exactly what is happening in the system.

[amigaksi]

I agree that too many buttons are unnecessary and make things too difficult to remember (PlayStation controllers are my example here), but I stand by too few also being an issue. Why would you not need a manual to look up which keys on the keyboard are for the hyperspace and smart bomb? There are something like 60 possibilities there instead of the 6 you'd have with e.g. a CD32 controller. It's something I never liked as I tended to play games holding the joystick base with one hand - look at the ZipStik and tell me how you use a keyboard without losing either the fire button or directional control...

It's any key to hyperspace and spacebar for smart bomb.  You may need the manual, but the most useful function is the one button to fire and it's to figure out what it does without any manual.  Hyperspace is hardly used to begin with so no sense in confusing things by putting 10+ buttons on the controller when only one or two matter most of the time.

[amigaksi]

For simple stuff like VGA, yes.

For more modern hardware this doesn't fly. Meaning that you can't actually access the 3D portions of your Nvidia GFX card the same way as your ATI GFX card or your onboard one.

Heck, from what I understand the implementations might not even be the same for different cards from the same company. Meaning a Nvidia 9600 and a Nvidia G260 might need altogether different ways of being accessed.

They don't do this to stop backwards compatibility, they do this because it's the best way to get high performance out of your chips. For a well documented example of why you sometimes need to break with the past to move on, look no further than Amiga AGA. That could have been so much more if Commodore had not tried so hard to keep compatibility and instead had designed a new chipset around more modern technology.

I don't agree with you at all.  I gave you the example of VGA-- it could have been implemented just as efficiently while maintaining hardware level compatibility.

[amigaksi]

Some important points here:



The BIOS is a software API... the very thing you are arguing against... in fact it was the fact that the BIOS abstracted the hardware that lead to the popularity of CP/M (the forerunner of MSDOS).

...

I said "it's not as bad" since you can still take over the hardware; mode switching is not used that often as say changing palettes, modifying a pixel, split-screening (to go back on topic for a moment), etc.  and you wouldn't have to be playing guessing games as to what the API is doing.  Just set the VESA mode once and then use the I/O ports and directly write to VGA.  If you don't need low-level accesses then use the API.

>And this is why we use APIs!!! Ok, so you have now successfully argued against yourself, maybe you understand

My argument has been the same-- it's better to have both.

[amigaksi]

On the contrary, when Creative had to go from ISA sound cards to PCI ones they had a HELLOVA time making them backwards compatible.  There is also an endless list of "soundblaster emulation" cards which never worked right as because they were "hardware compatible" they couldnt fix it.  However if you use a higher level API and software drivers you can easily patch any compatibility problems later.
...

"On the contrary" to what?  Did you like misread or skip some posts?  Sound cards are NOT backward compatible.  I stated an example where some Sound Blaster cards are backward compatible at the hardware level and they can be accessed directly with more efficiency.  I was stating that if they were all like that, that is better.  API restricts your access to hardware for what the function performs and it's inefficient.

>My god, I was upgrading in that era when they went from ISA to PCI for sound cards, half the time games wouldn't work properly.  Oh and lets not forget, soundblaster emulation on PCI sound cards is done in SOFTWARE, at least partially.  I believe its something to do with having to emulate the ISA chipset timings which is also why it did not work properly.

That's your speculation.  Some Soundblaster audio cards ISA and PCI versions of them are hardware compatible.  I can set use I/O locations 220h..22Fh and DMA/IRQs directly.  It's not being done in software as I explained before.

>The switch to Direct X brilliant as you very very rarely get this sort of problem anymore, it just works.  Kinda breaks your whole argument that backwards compatibility is easy.

No it doesn't break the argument, since you never understood the argument according to what you wrote.  APIs restricts your access to the hardware and is less efficient than directly writing to hardware registers if there is backward hardware compatibility.

>Now when talking graphics cards things get even worse as they are so much more complicated.  Do you REALLY think its cost effective to include legacy modes in every single new card you release?  

We're not talking about cost.  We're talking about what's better for using/programming-- is it better to modify a pixel color by doing a XOR [nnnn],EAX or by doing a call to an API?  Legacy mode should be a standard mode.  Some applications are undoable via API but can be done if direct hardware access is allowed.

>As for VESA, as I understand it that is still an API but it was mostly supported via the graphics card BIOS which is the only real difference between hardware and software support anyway.  

I said, "it's not as bad" meaning you can use it along with direct hardware access.  Since setting a mode is nonstandard, you can call it to set a graphics mode and then use direct I/O.  More later if needed.

[the_leander]

We're not talking about cost.  We're talking about what's better for using/programming-- is it better to modify a pixel color by doing a XOR [nnnn],EAX or by doing a call to an API?  Legacy mode should be a standard mode.  

That scream you can hear in the distance was the cries of every professional developer of every game and desktop apps studio in th industry crying out in horror at the concept of what you've just written.

Things move too fast and are now so complex that to support even a major subset of capabilities on modern hardware without an overall API to build upon as to make the suggestion completely no go. At best, you would end up with a situation where each software developer would effectively have to write and maintain their own (likely) incompatable layer which would then have to fight other softwares API in order to function.

At which point, you have just effectively rendered the whole point of having an OS completely meaningless.

Even Comodore saw the writing on the wall, with the A500 you had a copy of the schematics of the custom chips (or at least parts of) in order to allow for easier hardware banging. When systems are as simple as the Amiga, that's great. But you upgrade to a newer, better system and all of a sudden you're having to write off huge sections of your software base each time you do so. Which is why even by 2.0 there was a major shift in emphasis to OS friendly applications. The OS deals with the hardware and keeps everything ticking along and the software sits on top. The way things should be.

Some applications are undoable via API but can be done if direct hardware access is allowed.

Name three often used desktop applications that cannot by virtue of their function be made in an OS friendly fashion.

I said, "it's not as bad" meaning you can use it along with direct hardware access.  Since setting a mode is nonstandard, you can call it to set a graphics mode and then use direct I/O.  More later if needed.

I'd bet good money that there was a way within DirectX to call a non standard screensize.

The question would be though, why would you want to? Any monitor you use, be it CRT or LCD will only allow for a certain amount of resolutions. Seems to me you're doing things in a very cackhanded way.

[alexatkin]

And this is where I am confused.

The whole argument here seems to be, isn't it better to be able to address the hardware directly for maximum efficiency as an API will always run code that "is not necessarily efficient for what you want to do" and "you do not know EXACTLY what it is doing".

Well guess what, you CAN address hardware directly - but you would effectively to writing your own OS.  The sheer nature of using an off-the-shelf OS makes it impractical to allow banging the hardware directly.  Why?  So that one application does not prevent another application from working correctly.  

Bang the hardware the wrong way or at the wrong time and you take the whole OS down.  This is why Vista changed the driver model to split it into kernel/user code instead of all being kernel code. Low-level driver code is the cause of 99% of Windows crashes.  Now instead of a lockup its able to reinitialise your graphics card so you do not lose your work.  Even Linux developers are trying to move as much as possible into userland for stability reasons.

APIs are brilliant for 99.9% of development.  If they weren't, they wouldn't exist.  
The other 0.1% that you NEED to bang the hardware directly on, well quite frankly its unlikely to be a mass market application so why would it even matter that you might need to build PCs with EXACT specifications so your application/OS will run?  In fact, surely some sort of embedded board is more suitable where you can choose EXACTLY what hardware you use.  A multi purpose PC will never be efficient (or necessarily usable at all) for 100% of the things you might want to use a computer for, at least not without additional hardware (it was already mentioned there are plenty of nice PIC boards for precise timing applications, etc).

And here lies the whole point.  Why would manufacturers bother to put a HUGE extra workload onto themselves in order to make their hardware compatible for that 0.1% of the development community who needs low-level access?

I find it hard to see that having low-level access to the GPU would be helpful in any way.  The whole reason APIs are good is because the time it would take to code low-level is completely nullified by the increase in computing power in the meantime.  By the time you optimise your code for current hardware, you could easily do the same thing using an API with the THEN current hardware.

I have Windows 7 running on a PC below its minimum specifications and its stuck using the Standard VGA driver (VESA presumably) and its almost as fast as using the stock driver on XP.  Sure with a standard advanced 2D/3D API for all cards it would be even faster, but again that is impractical and it wouldn't cover every eventuality.  

Often there are more efficient ways to operate different make/model cards for specific applications (games).  With a software driver it can detect the game running and use optimisations for that game - done by the card manufacturer who knows the most efficient way to code for their card.  Using your standards-based 3D this would be impossible, it would be down to the developers to put more effort into detecting different cards and tweaking the settings accordingly and altering how the API translates to low-level code would be harder, as its on the BIOS instead of a software driver.

[persia]

Banging the hardware was a cheat, it allowed you to do things on the underpowered machines of the '80s that simply wouldn't be possible if you had to wait for the OS to do them.  The trade off was stability, you have code going around the already unstable OS to bang at hardware that may or may not have changed.  Amiga graphics were simple, a single chip and a few meg of RAM.  Today's graphics are much more complex, a half gig of RAM, a GPU and other hardware.  It's like comparing a sundial with an atomic clock, there is no comparison.

You have power, you have speed, you have an OS with memory protection and now you have drivers in user space.  Trying to bang the hardware in a dual quad core processor with GPU environment is just stupid.  Especially to try to read the bounce of a joystick...

You got a FSB in the GHz range, on a 4000 you've got a bus speed of max 25 MHz.  Your talking to the GPU over an order of magnitude faster than the Amiga talked to Fast RAM.

[ElPolloDiabl]

You got a FSB in the GHz range, on a 4000 you've got a bus speed of max 25 MHz

:hammer: Just to be a nitpicker if you look inside the case the Oscillator has 28.xxx Mhz on it. Agnus ran at 28.xxx Mhz the other chips, the chip bus the chip RAM and the Zorro slot bus ran at 7.xx Mhz. The CPU and FAST was free do it's own thing.

You are now de-loused.

[DamageX]

Banging the hardware was a cheat, it allowed you to do things on the underpowered machines of the '80s

Reality check: software is worthless without hardware to run it on. Rather than slamming what was once state of the art (I don't suppose you could have done better?) saying it was "underpowered" because it wasn't convenient for what you personally imagined was the One True Way of doing things, consider that people who wrote the naughty code ("cheat") actually created successful products.

The trade off was stability

The trade off was that you had to take the hardware specs into account before creating software to run on it. Stability has nothing to do with it. Flawed code continues to be flawed no matter whether it manipulates hardware or APIs.