linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@cs.anu.edu.au>
To: weasel@cs.stanford.edu
Cc: linuxppc-dev@lists.linuxppc.org, rth@cygnus.com
Subject: Re: [linux-fbdev] Re: readl() and friends and eieio on PPC
Date: Thu, 12 Aug 1999 14:52:24 +1000	[thread overview]
Message-ID: <199908120452.OAA30014@tango.anu.edu.au> (raw)
In-Reply-To: <v04210106b3d7d41042e2@[209.239.164.148]> (message from Peter Chang on Wed, 11 Aug 1999 18:39:11 -0700)


Peter Chang <weasel@cs.stanford.edu> wrote:

> When I did glide for the mac it definitely helped not do do an eieio 
> after every pci write. The current generations of 3dfx hw use a sw 
> managed fifo, and an eieio was only necessary when the sw layer 
> needed to do do things to insert a 'barrier' in the fifo for later 
> accounting.

Interesting.  What was the magnitude of the effect?  Are we talking
about 1%, 10%, or 100% faster?

This would have been from user level, right?  Driving a 3D card
through a kernel device driver would seem to be a bit painful.

Would it have been possible to use double-precision floating loads and
stores to transfer 8 bytes at a time?  That can double the available
bandwidth to PCI devices under some conditions.

Thinking about it, it seems to me that if your device needs to be fed
so fast that the eieio makes a difference, you *should* be feeding it
from user level rather than the kernel anyway, so then the behaviour
of readl/writel is irrelevant.

Paul.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

  reply	other threads:[~1999-08-12  4:52 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-08-09  8:17 readl() and friends and eieio on PPC Geert Uytterhoeven
1999-08-09 17:19 ` David A. Gatwood
1999-08-10  1:00 ` Paul Mackerras
1999-08-10  7:18   ` [linux-fbdev] " Jes Sorensen
1999-08-11  0:23     ` Paul Mackerras
1999-08-11  7:23       ` Jes Sorensen
1999-08-11  7:38         ` Richard Henderson
1999-08-12  0:13           ` Paul Mackerras
1999-08-12  1:39             ` Peter Chang
1999-08-12  4:52               ` Paul Mackerras [this message]
1999-08-12  6:17                 ` Peter Chang
1999-08-12  0:17           ` Paul Mackerras
1999-08-12  4:40             ` Richard Henderson
1999-08-12  5:00               ` Paul Mackerras
1999-08-12  5:43                 ` Richard Henderson
1999-08-12  7:07                   ` Paul Mackerras
1999-08-12  7:33                     ` Richard Henderson
1999-08-12  9:58                       ` Paul Mackerras
1999-08-12 12:31                     ` Geert Uytterhoeven
1999-08-13 12:18                       ` Paul Mackerras
1999-08-18 11:02                       ` Gabriel Paubert
1999-08-13 18:33                     ` Richard Henderson
1999-08-12  5:16               ` David Edelsohn
1999-08-12  5:27                 ` Paul Mackerras
1999-08-12  5:52                 ` Richard Henderson
1999-08-12  7:11                   ` Paul Mackerras
1999-08-12  7:32                 ` Jes Sorensen
1999-08-11 23:52         ` Paul Mackerras
1999-08-12  7:38           ` Jes Sorensen
1999-08-12 19:00           ` David A. Gatwood
1999-08-13  1:51             ` Paul Mackerras
     [not found] <Pine.LNX.3.96.990813143741.27557B-100000@mvista.com>
     [not found] ` <d3so5mdyta.fsf@lxp03.cern.ch>
1999-08-14 18:34   ` Geert Uytterhoeven
1999-08-14 18:36   ` David A. Gatwood
1999-08-14 19:48     ` Jes Sorensen
1999-08-15  1:28       ` David A. Gatwood
1999-08-14 21:39   ` Richard Henderson
1999-08-15 23:16   ` Paul Mackerras
1999-08-16  0:29     ` Richard Henderson
1999-08-16  7:11     ` Jes Sorensen
     [not found] <m3672hkxri.fsf@soma.andreas.org>
1999-08-15 13:39 ` James Simmons
     [not found] <d3pv0p72yr.fsf@lxp03.cern.ch>
1999-08-15 19:43 ` David A. Gatwood

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=199908120452.OAA30014@tango.anu.edu.au \
    --to=paulus@cs.anu.edu.au \
    --cc=Paul.Mackerras@cs.anu.edu.au \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=rth@cygnus.com \
    --cc=weasel@cs.stanford.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).