I just read this letter (I was off the list when it came out, Jul 5th)..
Subject: RE: AGP Chipset Support
From: Paul Sargent <Paul.Sargent@3dlabs.com>
Date: Mon, 5 Jul 1999 20:09:34 +0100
> That's not really a stupid question in the context of user space graphics
> drivers, but I'm playing with kernel level abstraction (much like fbcon or
> kgi) and one thing that interested me was getting AGP DMA to work + a few of
> the other AGP specific functions.
A nice little abstraction is merely to consider the AGP-GART "aperture" to be
a type of graphics-buffer memory "device." It just happens to be filled
with pages taken from main memory. The AGP bridge allows retrieval of the
data at the AGP card's leisure.
> As I understand it this involves some tweeking or the host chipset to set up
> (although it looks like the BIOS should do this at start of day). Also there
> is a address translation table called the GART which can be used for
> scatter-gather type operations (although I'm informed Intel is not telling
> anybody about how to use this at the moment).
We're using the GART now and have been for about 10 months or so for our
in-developement 3D server.
Essentially that GART allows a big swath of "CPU/AGP shared-memory" to be
created (for use by AGP cards) from a normal list of free physical memory
pages. It's like the AGP bridge is a "virtual process" with its own
virtual-page table... sharing a segment of memory that it owns.
This has obvious advantages when getting long lengths of physical
memory is difficult. 3D already requires vast amounts of storage to flow
into the engine. Main memory also is a very fast destination for the CPU to
write to and yet remain asynchronous with the AGP 3D card. Exploiting main
memory as a huge/fast funnel for CPU output, is the idea.
We're preparing to release a simple driver-patch/module built to be used
in our new X server, for R&D. We've been using a small, straightforward one
for our development work, and we haven't seen any real discussion of direct
AGP-bridge support.
We are prepared to support later kernel versions (for our EV2+ 3D X server)
with some simple binary modules sent along with the server... but would much
prefer that the AGP/GART be supported in a standard kernel.
> And finally I've heard that any memory allocated which is going to be read
> by AGP DMA has to be a special type.
-From what Herr Thomas (Thomas Roell) says, this is not true... it just has
to be memory reached within the GART table "window".
> You may notice that my above comments sound a little unsure of themselves.
> That's because all of my information comes from people writing drivers under
> Windows (NT or 95/8) so I don't know if these issues are really hardware
> issues or MS-isms because they've (for example) decided to allocate AGP
> memory out of a different pool.
I've no clue how it occurs there. It might be interesting to know how they
deal with the security/stability issues. Client-side rendering is the big
New Thing (scales with SMP) and so much CPU is needed along with the 3D
rendering.. it has to be done outside of a central server context, even with
a multithreaded one.
Is it that this doesn't present new problems, that aren't already dealt with
elsewhere on NT? (i.e. failing processes botch the graphics engine or mess
up the card or main X server)
> So I was just looking for people who may have already touched on it.
It's such a narrow focus, mostly for 3d graphics cards. Not many folks will
mention it as a priority. Still, we must use the hardware to its utmost.
> Paul
Subject: Re: AGP Chipset Support
From: Gerard Roudier <groudier@club-internet.fr>
Date: Mon, 5 Jul 1999 22:06:15 +0200 (MET DST)
g> But, the primary goal of AGP has been to allow 3D engines to execute
g> textures directly from main memory.
Exactement. The CPU can handle the not-so-trivial task of assembling
the proper set of textures and command buffers for execution.
g> Note that the AGP specifications seem to be close to obsolete before
g> having really been used. The AGP 4X allows up to 1 GB/s memory bandwitch
g> but some recent boards have an internal memory speed that is greater than
g> twice this value.
When it's replaced, we'll see. It doesn't really matter because 3D still
requires alot of accesses local to the card's side (in the framebuffer,
depth buffer etc..), so the AGP bus isn't the slowest part of the process.
g> In my opinion, if something that allows a 64 bit data path (32 bit
g> currently) and faster memory acces (currently up to 4x66Mhzx32bits) will
g> not be proposed by Intel in the short term, the AGP will fall into the
g> "oubliettes" of the I.T. very quickly.
I may not be the best one to know, but I feel that any means of 3D that
takes over the CPU entirely will not be the best way to effectively keep the
screen updated. SMP can do alot, but the tasks that are specific to the 3D
space of calculations are very specialized and relate to a user-viewed
output device, merely attempting to get the highest constant frame rate.
At times, the frames should even remain separated by a realtime delay.
I would guess these tasks are not easily mixable with a sensible list of
user tasks and constantly pre-emptive multitasking.
-- CH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/