Just some remarks:
- Even Einstein hasn't been able to imagine object addresses that depend
on the position of the observator but computer guys does. ;-)
- I cannot imagine a world where you have to use different mail address
depending on the town you send your mail from.
- Do you think that the Net would have had a so great success without the
URL concept?
On 15 Nov 1998, Jes Sorensen wrote:
> >>>>> "Gerard" == Gerard Roudier <groudier@club-internet.fr> writes:
>
> Gerard> Suppose that I want a device on a BUS to directly transfer
> Gerard> data to another device on the same BUS or to another one
> Gerard> without CPU intervention. How many keys must I pass to any BUS
> Gerard> abstraction layer to provide me the appropriate address values
> Gerard> I need?
>
> If you want inter PCI support, you will need to figure out an API for
> that. I don't know how Sun, DEC and others do this.
You misunderstood me. Any PCI device can use as a master a transaction
with another PCI device acting as a target. In PCI world, the host
bridge is able to act as a PCI master and as a PCI target and it
participates to the PCI bus this way.
> >> PCI bus won because it was far better than what was available in
> >> PC's before. However, PCI is SLOW and we are beginning to suffer
> >> from this now.
>
> Gerard> PCI specs allows 64 bit / 66 MHz transfers = 512 MB/sec.
>
> Except that you have to take into account that setting up a data
> transfers on a 64-bit bus takes exactly as long as setting up the
> transfer on a 32-bit bus, thus going from 32-bit to 64-bit PCI doesn't
> provice you with a 2x speed-up.
4 cycles for a write transaction and 5 cycles for read transaction due to
a turnaround cycle.
> Gerard> We haven't yet it because, IMO: 1 - It is significantly more
> Gerard> expensive than 32 bit PCI. 2 - It isn't worth it because 64
> Gerard> bit machines are not yet common due to lack of software taking
> Gerard> advantage of them. A 133 MHz PCI is also possible => 1 GB/s
>
> I agree that it is more expensive than 32-bit PCI, but one of the
> reasons for that is that people are not shipping 64-bit PCI in large
> numbers. The probably chose AGP because it's simpler and most standard
> PC owners care mainly about the performance of the 3D graphics in
> their latest game, thus no need for a generic bus.
AGP supports PCI transactions and AGP transactions in an interleaved way.
It is not a reliable bus so it cannot be used as a general data bus. The
fast write transaction is able to send data at up to 512 MB/sec to a frame
buffer for example and that is as fast as 64 bit/66 MHz PCI bus (if you
lose a bit, it is not a great problem). The rest of the AGP things are
pipelined transactions that allows AGP devices to use very efficiently the
main memory. On a well cached system, the memory bandwidth used by the CPU
is very low.
AGP is perhaps a bit shitty but it is highly tricky in my opinion.
> >> It's not the issue, btw. DEC has such systems as well. However on
> >> some architectures you map the bus to the memory/CPU when you need
> >> it and unmap it again after a DMA operation.
>
> Gerard> You still only consider CPU to BUS and BUS to CPU data
> Gerard> transfers only. Why not to envision applications where the
> Gerard> CPU controls all the data flaw but donnot have to route all
> Gerard> the data via the main memory?
>
> I consider BUS<->memory transactions which are the primary ones going
> with most high-performance devices. I don't care all that much about
> the speed for CPU<->device operations as you don't want to run
> high-performance devices in PIO mode (won't allow you to perform
> bursts on the bus and get the speed). I am not sure I understand your
> last comment though.
You misunderstood me there for the same reasons as I wrote above. I just
envision that part of the data may go directly from/to one _master_ device
to a _target_ device with obviously the _master_ bursting data.
I obviously donnot want to run PIO mode, especially on an address/data
multiplexed bus. I am certainly stupid but probably no so much, at least I
believe so.
Gerard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/