PC still playing Amiga catchup

[bloodline]

Ahh, cheers for that! I am curious though how it compares to other processors in the x86 family now though.

But again, thanks for pointing me to that.

While some members of the x86 family (I note the 286 and 386) were horrific fankenPuters... The x86_64 is actually pretty hot, AMD pretty much cleaned out all the old cruft and once the CPU is in "long mode", I can't think of a better* general purpose CPU right now



*it's pretty cheap too, always a bonus

[amigaksi]

What about A1 and SAM?

I'm only considering Amigas w/either OCS/ECS/ or AGA.

On what basis are those called "Amigas"?

[amigaksi]

fix'd.



Pithy. Amusing given that you're the one whose backside has been handed back to them on a plate on pretty much every single point you've made thus far too.

Can't understand English.  Just declaring them false statements won't help.  Every statement I made is correct.
Even DirectX is flawed which is irrelevant to my point is correct.  Before DirectX 1.0, I had video cards that supported OpenGL, 3D rendering, MPEG4, VGA standard, hardware accerated rendering, etc.  You are so biased, you only read those who reply to me and refuse to understand simple logical statements that are true regardless of what you say.

[amigaksi]

Again, I have to disagree with you. More on this in a sec.

>No, what it would usher in would be a whole new round of I/O, IRQ and DMA conflicts as different programs fought for control of hardware, oblivious to one another. As well as very painfully kludged hardware.



As I said in a previous post, that's all great for the very basics, but once you get into multiple layers of this and things become more complex, the hassle of maintaining this hardware compatability becomes emense, not to mention pointless - no desktop built in the last few years has a serial or parallel port, ISA hasn't been seen for over a decade and PCI has (largely) been discontinued, this is true especially of fast evolving things like graphics.
...

Complete rubbish-- didn't even address the point.  I gave an EXAMPLE of parallel port.  You can have hardware level compatibility for ANY DEVICE.

Re-read:
"No, if hardware was compatible like earlier VGA cards, they would use SAME I/O ports, same IRQs, same MEMORY MAP areas, etc. And even if you had multiple boards in the same system (in rare cases), there's the plug-n-play hardware that allows you to remap the I/O ports. Take another good example-- parallel ports are always mapped to 378h, 278h, 3BCh and using plug-n-play you can have 3 parallel ports and each one can be mapped to any of the standard I/O port locations."

>Now consider how much extra logic would have to be built into a modern gpu so as to include hardware compatability with just the major jumps in gpu design over the years...

When you add a brand new feature, you assing new standard I/O ports-- you maintain the previous ones.  Like they maintained CGA/EGA when making VGA.

Get a clue.

[amigaksi]

So you want it to be mainstream eh? I can do that...

USB2 Soundblaster Audigy2.

Ok perhaps that one too is a little OTT, but there are a great many other USB cards at much lower prices, and I'd bet good money that they too can sample at far, far higher rates then 1khz. I pointed to this one simply because it was the first one I found that had the sampling rate capabilities printed out up front. The other cards I looked at briefly are available to view here. Note that as laptops are becoming more and more popular, these sorts of external usb based expansions are becoming ever more mainstream.

In a way the above box is almost as though the hardware has gone full circle - many old soundcards included a gameport, now they're including usb ports...

You just stated something that doesn't even address the joystick 1Khz sampling.  It's a NEW piece of audio hardware.  I think they are plugging in USB 2.0 cards in Amigas as well.

[amigaksi]

Re-target capability.

...

If most of planet is PC-based, retarget capability is minor in comparison to what you get with hardware level compatibility:

(1) Faster code
(2) Faster response time (worst case analysis) and exactly knowing what is happening (for real-time stuff)
(3) No drivers required; they all use same driver (like VGA standard)
(4) Smaller and efficient code means less resources are used.
etc.

>Less efficient when dealing complex abstract objects.

I have yet to see someone here to prove to me that API is required once you make a piece of hardware have more functionality.  Making a piece of hardware more complex has no realtionship to whether it uses API-based compatibility or hardware compatibility.

>My CUDA GPU is faster than Amiga's changing palette capabilities i.e. the compute wavefront is larger. The purpose pixel shader is .... pixel processing.

"My" is the keyword.  Is it generic enough?

[mongo]

Before DirectX 1.0, I had video cards that supported OpenGL, 3D rendering, MPEG4, VGA standard, hardware accerated rendering, etc.

MPEG-4 came out 3 years after DirectX 1.0.

[amigaksi]

MPEG-4 came out 3 years after DirectX 1.0.

MPEG was there in the Matrox video cards and some ATI cards in early 1990s.  It may not be called MPEG4 but it was for video encoding/decoding.  Another big bug with DirectX was that it was API-based and hardly any existing video cards at the time supported it's functions.

[mongo]

MPEG was there in the Matrox video cards and some ATI cards in early 1990s.  It may not be called MPEG4 but it was for video encoding/decoding.

Nope.

Another big bug with DirectX was that it was API-based and hardly any existing video cards at the time supported it's functions.

How is this a bug, exactly?

Besides, DirectX isn't API based. It is an API.

[Karlos]

>My CUDA GPU is faster than Amiga's changing palette capabilities i.e. the compute wavefront is larger. The purpose pixel shader is .... pixel processing.

"My" is the keyword.  Is it generic enough?

Every GPU presently available is faster at writing to it's own register set than all versions of the amiga chipset are at changing their palette registers.

Even my old Permedia 2, which doesn't really count as being a GPU (there's no real programmability), can load it's RGB registers via the FIFO in less time than it takes OCS to do it.

Is that generic enough for you?

[GadgetMaster]

It seems like all the arguments are falling down. Why not just call it a day Amigaksi eh?

Come on! You've dragged this thread on for far too long. It stopped being funny a long time ago. :rolleyes:

[persia]

Why is is quicker to have the main CPU(s) interacting with the memory space of the GPU?  Is that just a waste of CPU cycles?  Why should the CPU even be concerned with graphics once it's passed off the information?  Aren't modern GPUs just and extension of what the Amiga was trying to do with it's graphics chips?  

In a way you could say that Amiga lost the computer race but it's ideas and goals won.

You just expressed your emotional fanaticism of PCs without even addressing the point.  It's better for PCs to have both APIs and hardware level compatibility than just API access.  You have less options with just API access.  Now given you just have APi access vs. an Amiga which has both, for certain real-time applications, Amiga does better.

If most of planet is PC-based, retarget capability is minor in comparison to what you get with hardware level compatibility:

(1) Faster code
(2) Faster response time (worst case analysis) and exactly knowing what is happening (for real-time stuff)
(3) No drivers required; they all use same driver (like VGA standard)
(4) Smaller and efficient code means less resources are used.
etc.

>Less efficient when dealing complex abstract objects.

I have yet to see someone here to prove to me that API is required once you make a piece of hardware have more functionality.  Making a piece of hardware more complex has no realtionship to whether it uses API-based compatibility or hardware compatibility.

>My CUDA GPU is faster than Amiga's changing palette capabilities i.e. the compute wavefront is larger. The purpose pixel shader is .... pixel processing.

"My" is the keyword.  Is it generic enough?

[koaftder]

It seems like all the arguments are falling down. Why not just call it a day Amigaksi eh?

Come on! You've dragged this thread on for far too long. It stopped being funny a long time ago. :rolleyes:

There comes a time when a man has to stand up and wipe the dung off his joystick.

[the_leander]

Complete rubbish-- didn't even address the point.  I gave an EXAMPLE of parallel port.  You can have hardware level compatibility for ANY DEVICE.

Your point was irrelevant as a parallel port from 20 years ago is still a parallel port today, it's not been improved upon or had its function changed in all that time. Yes you could get some PCI card to add back that functionality. But then you're fighting your own complaint about it being nonstandard. Things have changed. USB is pretty much all you'll find on the back of a PC these days. As I stated (and you ignored) once you move beyond the basics and start having to add support for as many layers as have been added to GPUs you are creating sreious headaches for yourself.

Re-read:

When you add a brand new feature, you assing new standard I/O ports-- you maintain the previous ones.  Like they maintained CGA/EGA when making VGA.

Not always, in some cases new I/O completely replaces the old, as with USB, as with things like hypertransport, as with things like PCI-E. With 3D effects being added and with huge architecture changes, maintaining the compatability for more then the basics, for GPU's would be a monumental pita and be hugely detrimental to performance.

Get a clue.

You first.

[the_leander]

If most of planet is PC-based, retarget capability is minor in comparison to what you get with hardware level compatibility:

(1) Faster code

On slower GPUs that take an order of magnitude longer to code for.

(2) Faster response time (worst case analysis) and exactly knowing what is happening (for real-time stuff)

Which works fine right up to the point your "perfect" app ends up in IRQ or I/O conflict with one or more other applications.

(3) No drivers required; they all use same driver (like VGA standard)

lulwut? Of course a driver is going to be required, do you seriously intend to have everyone write their own partial drivers implimenting only the bits they need... Your way would make Windows95 look stable by comparason.

(4) Smaller and efficient code means less resources are used.
etc.

Which you then have to make sure doesn't interact badly with other code also running, meaning having to test against hundreds if not thousands of other applications, each with their own custom code for accessing I/O, memory, GPU, sound etc.

I have yet to see someone here to prove to me that API is required once you make a piece of hardware have more functionality.  Making a piece of hardware more complex has no realtionship to whether it uses API-based compatibility or hardware compatibility.

It does when your application has to acces that functionality in terms of the time it takes to build, it is not that you get more functionality, it's that you get that functionality with far far less effort with an API.

[amigaksi]

Nope.

...

What's in a name?  "A rose by any other name would smell just as sweet."  Matrox card I still have supports MPEG in hardware.  DirectX isn't always doing it in hardware also if you want to get picky.

>How is this a bug, exactly?

Besides actual bugs, it's flawed that they gradually added functionality that already existed before it was introduced.  Why couldn't they do it in 1.0?

>Besides, DirectX isn't API based. It is an API.

They are both correct.