[haiku] Re: Accelerated versus double buffered.
- From: "Cyan" <cyanh256@xxxxxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Wed, 04 Mar 2009 21:16:00 GMT
Stephan Aßmus <superstippi@xxxxxx> wrote:
> But why does the graphics feel smoother and there is less strain on
> the CPU than with accelerated graphics?
I haven't tested with Haiku yet, but I did do some testing with the
Radeon driver a fair while back; I'm not sure if the results will be
of any use?
In any case, I was using a Radeon X300SE PCIe card with Euan's
"talkback release" driver under R5; this was about a year ago. The
regular Haiku driver at the time didn't support the X300SE, and even
the talkback release only supported the card in single-head mode.
However, I did give the acceleration engine a pretty good thrashing
because I was keen to know if the same timing problem that affects
Matrox cards also affected the Radeon. The problem I experienced
with Matrox cards is that whenever the accelerator is in use
(especially with lots of smaller operations, e.g. moving a window
behind several other windows), system timing jitter increases to
about 3ms, which causes two noticeable problems: audio breaks up
(buffer period is 667us, so that's about four buffers dropped), and
MIDI timing accuracy becomes too loose.
I'm not sure what the underlying cause is, whether it's interrupts
being disabled for too long, the PCI bus being blocked, etc. but it
affects both single- and multi-processor machines, Via and Intel
chipsets, and AGP and PCIe video cards equally.
Anyway, with the Radeon installed, the problem seemed to be
completely absent -- timing jitter was measured at around 20
microseconds even with lots of accelerator operations running.
I didn't notice any loss of smoothness either; in fact almost
everything relating to graphics was an order of magnitude faster than
with the PCIe x1 Matrox card installed (the Radeon is a PCIe x16
card).
So I'd have to say that with this particular version of the driver,
there were no performance bugs when used on R5's desktop, and when
manually invoking VRAM-to-VRAM blitter operations.
Stephan -- I'm not really familiar with how Haiku's app_server does
its drawing work, but I seem to recall that it double-buffers.
Is the off-screen bitmap (or bitmaps) stored in VRAM, or system RAM?
The reason I ask is because if all the drawing is done into a
system RAM bitmap by the CPU, wouldn't the acceleration engine be
pretty much unused except for performing a slight speedup for
RAM-to-VRAM DMA? In that situation it would seem that any performance
problems would come down to anything which restricted bus bandwidth,
maybe AGP write-combining settings?
Also, another thing that comes to mind is vertical retrace sync.
If the drawing is being done immediately without waiting for the
vertical retrace first, that can cause tearing and other ugly
artifacts which might go some way towards explaining flickering
terminal windows, etc. Or possibly more likely, if the vertical
retrace interrupt actually isn't triggering, so any waiting has to be
done for the full timeout period?
Just a thought anyway...
Other related posts:
