From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] image/memimage speed
Date: Fri, 5 Dec 2008 08:35:04 -0500 [thread overview]
Message-ID: <39cb2be32e592403f7336c6200cf56a3@quanstro.net> (raw)
In-Reply-To: <13426df10812042239pde2100dw696049def0160c4a@mail.gmail.com>
> If you're still seeing bad performance it may be because you need to
> fix up the MTRR or GART settings. I've done this dance and have no
> memory at this point of what you do, but vague memory is that proper
> MTRR settings with a good PCIe card will give you far better bandwidth
> than the old AGP cards. There is nothing like the 60x assymetry.
i don't think this is the case. if you recall from the original
post, i have used the pat registers to set up memory types on
a pcie card and i do see dramatic speedups for drawing to
the screen. however, reading from the screen is just as slow
as before.
according to the intel's x86 arch guide vol 3a, §10-8, p. 466
speculative reads are allowed for WC/WT/WB memory. so
i wouldn't think that it's a bus problem at all.
if you recall, the only difficulty in using subpixel
fonts a few years ago was the fact that for hold mode and
deselection, the the α draw was done with the new mask and
the on-screen image, which was read from the frame buffer.
not only did this result in a squared α, it was also sloooow,
especially on nvidia cards. oddly, the via machines driven
in vesa mode were the fastest. the speed up was at least a
factor of 10; you could easily see the speedup.
at this point, you probablly don't believe me. so maybe
some numbers will help make the case:
; time dd -if /dev/wsys/1/screen -of /dev/null -bs 512k
0+1201 records in
0+1201 records out
0.00u 0.03s 4.04r dd -if /dev/wsys/1/screen -of /dev/null ...
; time dd -if /dev/zero -of /dev/null -bs 512k -count 1201
1201+0 records in
1201+0 records out
0.00u 0.14s 0.14r dd -if /dev/zero -of /dev/null ...
i've seen the same behavior on a number of different nvidia
cards of different generations. newer cards seem to be worse
than older cards. (if you have the programming interface
manuals, i'd be happy to double-check the settings. ☺.)
can you explain what the downside of double-buffering
would be? it's not like the days where we asked, hey buddy,
have you got 4 megs to spare?
- erik
next prev parent reply other threads:[~2008-12-05 13:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-30 22:00 Iruata Souza
2008-11-30 23:54 ` Iruata Souza
2008-12-01 1:29 ` erik quanstrom
2008-12-01 1:54 ` andrey mirtchovski
2008-12-01 2:35 ` erik quanstrom
2008-12-01 3:30 ` andrey mirtchovski
2008-12-01 6:41 ` Paul Lalonde
2008-12-01 14:19 ` Steve Simon
2008-12-01 14:33 ` erik quanstrom
2008-12-05 6:39 ` ron minnich
2008-12-05 13:35 ` erik quanstrom [this message]
2008-12-05 18:27 ` Russ Cox
2008-12-05 18:32 ` Russ Cox
2008-12-05 18:49 ` ron minnich
2008-12-05 19:21 ` Paul Lalonde
2008-12-05 19:25 ` erik quanstrom
2008-12-05 19:30 ` Paul Lalonde
2008-12-05 19:40 ` erik quanstrom
2008-12-05 20:11 ` ron minnich
2008-12-06 5:52 ` Paul Lalonde
2008-12-07 17:00 ` Aki Nyrhinen
2008-12-07 23:22 ` erik quanstrom
2008-12-08 0:17 ` Aki Nyrhinen
2008-12-01 15:24 plalonde
2008-12-05 5:22 ` sqweek
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=39cb2be32e592403f7336c6200cf56a3@quanstro.net \
--to=quanstro@quanstro.net \
--cc=9fans@9fans.net \
/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).