HI !
> > > IMO, that switching to kernel mode, copying data structures, and re-
> > > turning back into user mode, may be too much time, and maybe when the
> > > ioctl returns, you haven't enough time to copy your buffer.
> > No. That shouldn't matter much. I once measured a full ioctl round trip on
> > my old 486 to take 600 cycles. Given even that machine (486/66), this gives
> > an extra delay of about 10 microseconds. Shouldn't be the crucial point.
> If you are drawing objects with little polygons (i.e. a torus with
> many polygon resolution), where each polygon can take 300 cycles or less,
> it's very crucial, I think.
We were talking about the return from a waitretrace type IOCTL. If you draw
lots of Poly's afterwards, it will be a matter of one ploy more or less than can be
drawn without flicker.
> In fact, in 2D accel, I only draw hlines by hardware when they are
> more than 100 pixels in length, because if they are shorter, drawing by
> hardware is mucho more slow (because of the ioctl call?).
Yes. ioctl overhead is - as said - about 600 cycles on a 486, maybe less
on newer archs.
This is also why LibGGI originally had heuristics on when not to try
acceleration. We should put those back in btw ...
CU, Andy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
