Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch (More info?)
KR Williams wrote:
> In article <1084811783.515695@teapot.planet.gong>, roo@try-
> removing-this.darkboong.demon.co.uk says...
[SNIP]
>>If you consider putting shitloads of RAM onto the graphics card
>>a solution I don't think it slowed that down at all. What it did
>>enable was low-cost solutions *at the time it came out*, the kind
>>of solutions that would suit kiddies who would break their piggy
>>bank to play a game.
>
>
> That's *precisely* what I advocated at the time. Memory sizes
> grew (and costs fell) to where this was not only possible, but
> mandatory at the same time AGP became available. Indeed the only
> things that used AGP (system memory resident) textures were Intel
> demos. Impressive, but hardly useful. Graphics cars have
> outstripped AGP usage ever since.
>
>>[SNIP]
>>
>>
>>>I may have a tough spot in my soul for Intel, dreaming for what
>>>might have been (and technically possible), but you're a lackey
>>
>>OK, I'll bite. What might have been when AGP was first mooted ?
>
>
> The first day it was shipped in a product. Graphics cards were
> even then shipping with more (texture) memory than the games of
> the day were using. It was a *bad* idea, much like UMA. Memory
> is and was cheap. 32MB cards were normal then, and 128MB cheap
> now. There would be even more memory on graphics cards if there
> were a reason. Like I said earlier, even my 2D card has 32MB.
So your suggestion that "Indeed, perhaps AGP put off better
solutions many years" does not in fact apply to the better solution
that you personally advocated. OK, I let's say I accept that the
card fetching textures itself while leaving the CPU to get on and
do other work is a waste of time because your advocated solution
was applied.
How about the bandwidth aspect of AGP ? What else was out there
to provide that at the time ?
>> > for what is. I'm quite sure you don't treat M$ so kindly for
>>
>>In the context of this discussion your assertion of being a "lackey
>>for what is" is wrong anyway. It flatly ignores my preference which
>>is render into main memory and DMA the framebuffer to the RAMDAC.
>
>
> Oh, my! NO wonder we disagree so much. I have *NO* interest in
> bottling up main memory with such trivia. I'm sure you liked UMA
> too. Let me ask you; Do you have an integrated UMA graphics
> controller on your system?
>
>
>>Nice and simple, lots of control for the programmer. However I do
>>recognise this is not a good solution right now because of the way
>>the hardware is structured and the design trade-offs.
>
>
> It is a *horrible* idea. It puts too much stress on the exact
> wrong area of the system. UMA not only affects memory bandwidth,
> but latency. I'd rather not give up either and throw it all at
It can do, depending on how you design your memory subsystem. If
you go the dumb route and just introduce wait states - it'll hurt,
if you go the smart route and have seperate banks of RAM it'll
hurt less (Amiga Low mem/Fast mem). If you can find some VRAM it
will hurt even less, fun stuff to work with.
> the processor. Perhaps it's because I know what's possible in
> hardware and you're simply dreaming of a perfect world (again).
[SNIP]
> Amazing the difference in perspective between hardware wonks and
> software weenies. ;-)
Or people who lived breathed and worked next to folks who produced
the first 32 bit uP to integrate FPU and static RAM. Someone who
also happened to spend a large amount of time working with the
graphics stuff they did there too. They *did* do UMA, but they
used VRAM, which made everything very easy (although costly).
I have to say that I did enjoy figuring out to get a ~300MFLOP
crate of T800s munging fractals and piping the data into a dinky
little 1280x1024x24 framebuffer via four 20mbit pipes. Would love
to have another crack at that crate with what I know now.
That was a long time ago and the wheel of incarnation has made a
half-turn since then.
Cheers,
Rupert
KR Williams wrote:
> In article <1084811783.515695@teapot.planet.gong>, roo@try-
> removing-this.darkboong.demon.co.uk says...
[SNIP]
>>If you consider putting shitloads of RAM onto the graphics card
>>a solution I don't think it slowed that down at all. What it did
>>enable was low-cost solutions *at the time it came out*, the kind
>>of solutions that would suit kiddies who would break their piggy
>>bank to play a game.
>
>
> That's *precisely* what I advocated at the time. Memory sizes
> grew (and costs fell) to where this was not only possible, but
> mandatory at the same time AGP became available. Indeed the only
> things that used AGP (system memory resident) textures were Intel
> demos. Impressive, but hardly useful. Graphics cars have
> outstripped AGP usage ever since.
>
>>[SNIP]
>>
>>
>>>I may have a tough spot in my soul for Intel, dreaming for what
>>>might have been (and technically possible), but you're a lackey
>>
>>OK, I'll bite. What might have been when AGP was first mooted ?
>
>
> The first day it was shipped in a product. Graphics cards were
> even then shipping with more (texture) memory than the games of
> the day were using. It was a *bad* idea, much like UMA. Memory
> is and was cheap. 32MB cards were normal then, and 128MB cheap
> now. There would be even more memory on graphics cards if there
> were a reason. Like I said earlier, even my 2D card has 32MB.
So your suggestion that "Indeed, perhaps AGP put off better
solutions many years" does not in fact apply to the better solution
that you personally advocated. OK, I let's say I accept that the
card fetching textures itself while leaving the CPU to get on and
do other work is a waste of time because your advocated solution
was applied.
How about the bandwidth aspect of AGP ? What else was out there
to provide that at the time ?
>> > for what is. I'm quite sure you don't treat M$ so kindly for
>>
>>In the context of this discussion your assertion of being a "lackey
>>for what is" is wrong anyway. It flatly ignores my preference which
>>is render into main memory and DMA the framebuffer to the RAMDAC.
>
>
> Oh, my! NO wonder we disagree so much. I have *NO* interest in
> bottling up main memory with such trivia. I'm sure you liked UMA
> too. Let me ask you; Do you have an integrated UMA graphics
> controller on your system?
>
>
>>Nice and simple, lots of control for the programmer. However I do
>>recognise this is not a good solution right now because of the way
>>the hardware is structured and the design trade-offs.
>
>
> It is a *horrible* idea. It puts too much stress on the exact
> wrong area of the system. UMA not only affects memory bandwidth,
> but latency. I'd rather not give up either and throw it all at
It can do, depending on how you design your memory subsystem. If
you go the dumb route and just introduce wait states - it'll hurt,
if you go the smart route and have seperate banks of RAM it'll
hurt less (Amiga Low mem/Fast mem). If you can find some VRAM it
will hurt even less, fun stuff to work with.
> the processor. Perhaps it's because I know what's possible in
> hardware and you're simply dreaming of a perfect world (again).
[SNIP]
> Amazing the difference in perspective between hardware wonks and
> software weenies. ;-)
Or people who lived breathed and worked next to folks who produced
the first 32 bit uP to integrate FPU and static RAM. Someone who
also happened to spend a large amount of time working with the
graphics stuff they did there too. They *did* do UMA, but they
used VRAM, which made everything very easy (although costly).
I have to say that I did enjoy figuring out to get a ~300MFLOP
crate of T800s munging fractals and piping the data into a dinky
little 1280x1024x24 framebuffer via four 20mbit pipes. Would love
to have another crack at that crate with what I know now.
That was a long time ago and the wheel of incarnation has made a
half-turn since then.
Cheers,
Rupert
Facebook
Twitter
Instagram