9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] nvidia scrolling performance
Date: Sun, 30 Apr 2006 19:52:58 -0500	[thread overview]
Message-ID: <bcfd5d660ea61c5a27957d613b82437d@quanstro.net> (raw)

i only have a pci card, but someone with an agp card and a machine that
allows bios-controlled agp bandwidth could eliminate some possibilities.
if it's bus limited, then the total performance should be linear in agp
bus speed, right?  of course we still wouldn't know which direction on
the bus was limiting.

perhaps it's time to add another machine to the second-hand hardware collection.
;-)

pci-x (1.066G/s) has the same bandwidth as PCIe x4 (1G/s).
PCIe SLI = 2 * 16x = 8G/s, which ought to be enough for just about anyone.

- erik

On Sun Apr 30 13:13:21 CDT 2006, steve@quintile.net wrote:
> > Frame buffer memory is very very slow to read from,
> > and not just on nvidia.  When I did some timings six years
> > ago, I found that reading from frame buffer memory
> > was slower than reading from disk.  I'm sure the situation
> > hasn't gotten better.  It's not on the fast path for any
> > other system, so the vendors just don't care.
>
> I may be talking rubbish but I understood this is a fundamental
> problem with reading VGA memory over the PCI bus. VGA cards are
> designed for fast writes and not fast reads.
>
> People have been very interested in using the GCPUs in graphics cards
> to do video processing (to disk rather than for display) but the limiting
> factor seems to have been the speed at which data can be read back.
> I do hear that some cards are appearing with dual PCIX which will allow
> symetric access speeds to the frame buffer.
>
> -Steve
>


             reply	other threads:[~2006-05-01  0:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-01  0:52 erik quanstrom [this message]
2006-05-01  1:00 ` Paul Lalonde
2006-05-02 22:55 ` [9fans] " Paweł Lasek
  -- strict thread matches above, loose matches on Subject: below --
2006-05-05 18:08 [9fans] " erik quanstrom
2006-05-05 17:22 erik quanstrom
2006-05-05 17:32 ` Paul Lalonde
2006-05-05 16:08 erik quanstrom
2006-05-05 16:42 ` David Leimbach
2006-05-05 15:46 erik quanstrom
2006-05-05 15:56 ` Paul Lalonde
2006-05-05 16:01   ` David Leimbach
2006-05-05 16:21     ` Paul Lalonde
2006-05-05 16:59       ` David Leimbach
2006-05-05 16:05   ` Wes
2006-05-05 17:07   ` Ronald G Minnich
2006-05-05 17:30     ` Paul Lalonde
2006-05-01  0:30 erik quanstrom
2006-05-01 17:44 ` Russ Cox
2006-05-01 17:57   ` Artem Letko
2006-05-01 19:02     ` Russ Cox
2006-04-29 21:39 erik quanstrom
2006-04-30  4:00 ` jmk
2006-04-30 16:10 ` Russ Cox
2006-04-30 18:12   ` Steve Simon
2006-04-30 22:34     ` Ronald G Minnich
2006-05-01  6:52       ` Nigel Roles
2006-05-01 19:58         ` Ronald G Minnich
2006-05-01 20:10           ` David Leimbach

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bcfd5d660ea61c5a27957d613b82437d@quanstro.net \
    --to=quanstro@quanstro.net \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).