On Thu, 17 Mar 2005 15:16:22 -0500, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> Since everybody likes this idea, I'll take the contrary position.
>
> * There is no advantage to being able to reuse consumed pages in
> random order versus a fixed order
Well, that depends on whether it's a fixed set or not.
>
> * Another way to grow/shrink the ring buffer is to have a predefined
> list of pages as I described earlier
What I meant was to grow/shrink the NUMBER of pages. The amount of
unconsumed data in the ring buffer will always be variable in size.
>
> * This is more complicated for the driver than a simple, virtually
> contiguous buffer
Not by much.
if (there is enough room to add this command plus a link to the next buffer) {
add the requested packet;
} else {
add a link to the next buffer;
select the next buffer;
add the requested packet;
}
> * I imagine the hardware is more complicated as well
Maybe, maybe not.
> * On PCI-e, the interrupt rate may be too high (see below)
This isn't about interrupts. An interrupt would occur only when the
number of unconsumed words in the buffer falls below a certain number.
In this case, that number would have to be tracked independently of
the pointers (whereas in the fixed case, they are one and the same),
but that is all. Following a chain of linked buffers would not in and
of itself assert an interrupt signal.
> Interrupt rate: on PCI, the ring buffer will drain at a rate of 16
> ms/page, using my earlier estimate of 256 bytes/millisecond drain rate
> for 4K texture pages, so that is ok. But on PCI-e the drain rate may
> be 30 to 60 times higher, giving an uncomfortably high interrupt rate.
> The fixed set scheme does not have this problem.
>
> So there aren't any advantages that I can see, over a scheme that
> preloads a fixed set of physical pages for the ring buffer, while there
> are drawbacks.
And the question is: For a fixed set, how many pages is enough?
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
