All of lore.kernel.org
 help / color / mirror / Atom feed
* problem: reading from (rivafb) framebuffer is really slow
@ 2001-05-18  1:29 Felix von Leitner
  2001-05-18  7:46 ` Alan Cox
  2001-05-18 18:43 ` James Simmons
  0 siblings, 2 replies; 3+ messages in thread
From: Felix von Leitner @ 2001-05-18  1:29 UTC (permalink / raw)
  To: linux-kernel

When benchmarking DirectFB, I found that a typical software alpha
blending rectangle fill is completely dominated (I'm talking 90% of the
CPU cycles here) by the time it takes to read pixels from the
framebuffer.

The pixels are read linearly in chunks of aligned 32-bit words.  It's a
Geforce 2 GTS in 1024x768 with 32-bit color depth using rivafb.  This
looks quite crass to me.  Any ideas?  Maybe rivafb does not initialize
AGP and the card is in PCI mode or something?

Felix

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: problem: reading from (rivafb) framebuffer is really slow
  2001-05-18  1:29 problem: reading from (rivafb) framebuffer is really slow Felix von Leitner
@ 2001-05-18  7:46 ` Alan Cox
  2001-05-18 18:43 ` James Simmons
  1 sibling, 0 replies; 3+ messages in thread
From: Alan Cox @ 2001-05-18  7:46 UTC (permalink / raw)
  To: Felix von Leitner; +Cc: linux-kernel

> When benchmarking DirectFB, I found that a typical software alpha
> blending rectangle fill is completely dominated (I'm talking 90% of the
> CPU cycles here) by the time it takes to read pixels from the
> framebuffer.

I would expect that. Guess why X11 is designed not to do this.

> The pixels are read linearly in chunks of aligned 32-bit words.  It's a
> Geforce 2 GTS in 1024x768 with 32-bit color depth using rivafb.  This
> looks quite crass to me.  Any ideas?  Maybe rivafb does not initialize
> AGP and the card is in PCI mode or something?

Writes across the PCI bus are posted, and potentially merged. Read posting is
rather harder to do. This is one reason to keep copies of data or to use
DMA or textures from AGP space to speed up access to the data you need.

In general pci write = fast, pci read = slow. High performance subsystems
you write to their pci memory they DMA back to your main memory. 

Alan


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: problem: reading from (rivafb) framebuffer is really slow
  2001-05-18  1:29 problem: reading from (rivafb) framebuffer is really slow Felix von Leitner
  2001-05-18  7:46 ` Alan Cox
@ 2001-05-18 18:43 ` James Simmons
  1 sibling, 0 replies; 3+ messages in thread
From: James Simmons @ 2001-05-18 18:43 UTC (permalink / raw)
  To: Felix von Leitner; +Cc: linux-kernel


> When benchmarking DirectFB, I found that a typical software alpha
> blending rectangle fill is completely dominated (I'm talking 90% of the
> CPU cycles here) by the time it takes to read pixels from the
> framebuffer.

Note the SOFTWARE alpha blending rectangle fill. You are passing alot of
data over the bus. So slooooooooow. If you implement a accelerated
function you will not have this problem.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2001-05-18 18:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-05-18  1:29 problem: reading from (rivafb) framebuffer is really slow Felix von Leitner
2001-05-18  7:46 ` Alan Cox
2001-05-18 18:43 ` James Simmons

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.