Re: Max retry ECR

[br@ELSA.de]

I don't quite see the problem.

The gfx controller can be designed to complete the frame buffer accesses
(e.g. direct draw) bypassing the 2D/3D pipeline/engine. If arbitration at
the frame buffer is done right, this will result in a maximum competion
time well under 10us.

The out-of-order issues that arise don't apply, sind the DDraw App has no
ordering with the driver accesses anyway.


I would, however, suggest an exemption from the 10us limit during boot
time, e.g. when the BIOS is loaded off the (video) card. Accessing 32bit
word from a (serial) ROM device off chip can take some time, but it would
not hurt any other device during boot time.

Bernhard






Secret Squirrel <anon@squirrel.owl.de> on 03.06.98 21:43:26

To:   Mailing List Recipients <pci-sig-request@znyx.com>
CC:    (Blindkopie: Bernhard Bender/ELSA/DE)
Subj: Max retry ECR




The new "Maximum Completion Time" ECR seems like one that will be
impossible for PC graphics adapter vendors to comply with.

Assume, as the ECR explicitly does, that there is a PCI device that
cannot retire every transaction in under 10us.  The ECR states that
the driver for that device is then responsible for ensuring that a
transaction cannot be sent when the device will retry the transaction
for over 10us.  That would be fine, except that PC graphics adapters
have to live in the world of Microsoft DirectDraw (TM).  DirectDraw
allows applications to write directly to the hardware device without
the intervention of a driver.  It is therefore impossible to solve the
maximum completion time via the driver, as suggested by the ECN, for a
PC graphics card since the data never passes through the driver.  In
fact, it is impossible to solve the problem at all if the hardware can
in any circumstances take more than 10us to retire any transaction.

This problem is likely to be even more pronounced with 3D graphics
adapters, where individual commands on the PCI bus can cause
operations like buffer clears or drawing of polygons that fill the
entire screen.  Hmm, let's say we have a 100MHz clock on a chip that
can draw a pixel every clock, and a mid-range monitor:
1280x1024x10ns=13us to draw a single object.  Granted, 3D operations
don't bypass the driver, but 2D operations subsequent to them can.

So, why have an ECR that cannot be complied with?  Unless someone
doesn't want graphics controllers to be able to comply...