Linus Torvalds wrote:
A hot system call takes about 0.2 us on an athlon (it takes significantly
longer on a P4, which I'm beating up Intel over all the time). The ioctl
stuff goes through slightly more layers, but we're not talking huge
numbers here. The system calls are fast enough that
On Mon, 27 May 2002, Jens Owen wrote:
This is an education for me, too. Thanks for the info. Any idea how
heavy IOCTL's are on a P4?
Much heavier. For some yet unexplained reason, a P4 takes about 1us to do
a simple system call. That's on a 1.8GHz system, so it basically implies
that a P4
Linus Torvalds wrote:
On Mon, 27 May 2002, Jens Owen wrote:
This is an education for me, too. Thanks for the info. Any idea how
heavy IOCTL's are on a P4?
Much heavier. For some yet unexplained reason, a P4 takes about 1us to do
a simple system call. That's on a 1.8GHz system, so it
Keith Whitwell wrote:
Linus Torvalds wrote:
On Mon, 27 May 2002, Jens Owen wrote:
This is an education for me, too. Thanks for the info. Any idea how
heavy IOCTL's are on a P4?
Much heavier. For some yet unexplained reason, a P4 takes about 1us to do
a simple system call.
On 2002.05.27 16:28 Jens Owen wrote:
...
If we do get some type of indirect rendering path working quicker, then
perhaps we could tighten up these defaults so that the usage model
required explicit administrative permision to a user before being
allowed access to direct rendering.
On Mon, 27 May 2002, Keith Whitwell wrote:
Linus Torvalds wrote:
Much heavier. For some yet unexplained reason, a P4 takes about 1us to do
a simple system call. That's on a 1.8GHz system, so it basically implies
that a P4 takes 1800 cycles to do a int 0x80 + iret, which is just
From a game standpoint, think quake engine. The actual game doesn't need
to tell the GX engine everything over and over again all the time. It
tells it the basic stuff once, and then it just says render me. You
don't need DRI for sending the render me command, you need DRI because
you send
Around 18 o'clock on May 27, Keith Whitwell wrote:
I think the multiplayer aspects of the game are a separate issue. Talking
about the difference between a big display list with the whole quake level in
it and the visibility/bsp-tree/whatever-new-technique coding that quake
other games
Keith Packard wrote:
We had a big display-list vs immediate-mode war around 1990 and immediate
mode won. It's just a lot easier to send the whole frame worth of
polygons each time than to try an edit display lists. Of course, this
particular battle was framed by the scientific
José Fonseca wrote:
On 2002.05.27 16:28 Jens Owen wrote:
...
If we do get some type of indirect rendering path working quicker, then
perhaps we could tighten up these defaults so that the usage model
required explicit administrative permision to a user before being
allowed access
On Mon, 27 May 2002 15:01:47 -0600
Jens Owen [EMAIL PROTECTED] wrote:
1) We loosen security requirements for 3D drivers. This will allow
far less data copying, memory mapping/unmapping and system calls.
Many modern graphics chips can have their data managed completely in a
user space AGP
Ian Molton wrote:
On Mon, 27 May 2002 15:01:47 -0600
Jens Owen [EMAIL PROTECTED] wrote:
1) We loosen security requirements for 3D drivers. This will allow
far less data copying, memory mapping/unmapping and system calls.
Many modern graphics chips can have their data managed completely in
Linus and Keith P.,
Thank you very much for your valuable insights - they cleared a
misconception I had about memory transfers.
Of course, to get to the bottom of this, we will have to test several
buffer sizes - I'm sure it will be an interesting study.
Regards,
José Fonseca
On 2002.05.25 06:10 Leif Delgass wrote:
On Fri, 24 May 2002, Frank C. Earl wrote:
On Thursday 23 May 2002 04:37 pm, Leif Delgass wrote:
I've committed code to read BM_GUI_TABLE to reclaim processed buffers
and
disabled frame and buffer aging with the pattern registers. I've
On Saturday 25 May 2002 12:10 am, Leif Delgass wrote:
So it would appear that allowing clients to add register commands to a
buffer without verifying them is _not_ secure. This is going to make
things harder, especially for vertex buffers. This is going to require
copying buffers and
On Saturday 25 May 2002 03:01 am, José Fonseca wrote:
Wow! Bummer... I already had convinced myself that the card was secure!
It is, if you don't rely on a register being set by something for your
control of things. You may get peak performance with the design in question,
but it's not
On 2002.05.25 17:16 Frank C. Earl wrote:
On Saturday 25 May 2002 03:01 am, José Fonseca wrote:
Wow! Bummer... I already had convinced myself that the card was secure!
It is, if you don't rely on a register being set by something for your
control of things. ...
Frank, Leif was pretty
Forgot to cc the list...
--
Leif Delgass
http://www.retinalburn.net
-- Forwarded message --
Date: Sat, 25 May 2002 12:56:08 -0400 (EDT)
From: Leif Delgass [EMAIL PROTECTED]
To: Frank C. Earl [EMAIL PROTECTED]
Subject: Re: [Dri-devel] Mach64 dma fixes
On Sat, 25 May 2002
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
On 2002.05.25 17:16 Frank C. Earl wrote:
Frank, Leif was pretty clear and I quote:
it IS possible to derail a bus master in progress and set it
processing from a different table in mid-stream. Plus, if the address is
bogus or the
On Saturday 25 May 2002 11:56 am, you wrote:
What prevents a client from modifying the contents of a buffer after it's
been submitted? Sure, you can't send new buffers without the lock, but
the client can still write to a buffer that's already been submitted and
dispatched without holding
On Sat, 25 May 2002, Frank C. Earl wrote:
On Saturday 25 May 2002 11:56 am, you wrote:
What prevents a client from modifying the contents of a buffer after it's
been submitted? Sure, you can't send new buffers without the lock, but
the client can still write to a buffer that's already
Frank,
On 2002.05.25 18:24 Frank C. Earl wrote:
... This is extremely disappointing to say the least. Doing the
copying is going to eat at least part if not all the advantage of doing
either route.
Yes, it's something we have to deal regardless of how we flush the DMA
buffers..
Of course
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
So if you can't secure it in the end, your extra effort will be in vain.
I just thought of something to try to change the nature of the test case
problem. What happens if you have a second descriptor of commands that
merely resets the
On Saturday 25 May 2002 01:14 pm, Leif Delgass wrote:
I'm using the same model you had set up. When a client submits a buffer,
it's added to the queue (but not dispatched) and there's no blocking.
The DRM batch submits buffers when the high water mark is reached or the
flush ioctl is called
On 2002.05.25 20:36 Frank C. Earl wrote:
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
So if you can't secure it in the end, your extra effort will be in
vain.
I just thought of something to try to change the nature of the test case
problem. What happens if you have a second
On Sat, 25 May 2002, José Fonseca wrote:
On 2002.05.25 20:36 Frank C. Earl wrote:
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
So if you can't secure it in the end, your extra effort will be in
vain.
I just thought of something to try to change the nature of the test
On Sat, 25 May 2002, Leif Delgass wrote:
On Sat, 25 May 2002, José Fonseca wrote:
On 2002.05.25 20:36 Frank C. Earl wrote:
On Saturday 25 May 2002 11:48 am, José Fonseca wrote:
So if you can't secure it in the end, your extra effort will be in
vain.
I just thought of
On Saturday 25 May 2002 03:44 pm, Leif Delgass wrote:
This had crossed my mind too. The only problem is that there could still
be a short period of time where BM_GUI_TABLE isn't accurate, so it still
leaves the problem of being able to trust the contents of BM_GUI_TABLE for
buffer aging and
On Saturday 25 May 2002 03:50 pm, Leif Delgass wrote:
It just occurred to me that resetting BM_GUI_TABLE could put the card into
a loop. You might have to put in an address two descriptors away. We'd
need to test this.
Hmm... Didn't think about that possibility. I had this last line of
On 2002.05.25 21:50 Leif Delgass wrote:
On Sat, 25 May 2002, Leif Delgass wrote:
On Sat, 25 May 2002, José Fonseca wrote:
...
This had crossed my mind too. The only problem is that there could
still
be a short period of time where BM_GUI_TABLE isn't accurate, so it
still
On Saturday 25 May 2002 04:27 pm, you wrote:
Anyway, this doesn't prevent to use the buffer aging. On the end of
processing a buffer we still end up with the correct value of BM_GUI_TABLE
and we can use the last bit of BM_COMMAND to know if it's processing the
last entry or not. The only
On Sat, 25 May 2002, Frank C. Earl wrote:
Linus, if you're still listening in, can you spare us a moment to tell us
what consequences quickly mapping and unmapping memory reigons into userspace
has on the system?
It's reasonably fine on UP, and it often _really_ sucks on SMP.
On UP, the
On 2002.05.26 00:49 Linus Torvalds wrote:
On Sat, 25 May 2002, Frank C. Earl wrote:
Linus, if you're still listening in, can you spare us a moment to tell
us
what consequences quickly mapping and unmapping memory reigons into
userspace
has on the system?
It's reasonably fine on
On Sun, 26 May 2002, José Fonseca wrote:
The vertex data alone (no textures here) can be several MBs per frame
Yes, yes, I realize that the cumulative sizes are big. The question is not
the absolute size, but the size of one bunch.
Throwing some numbers just to get a rough idea:
Around 18 o'clock on May 25, Linus Torvalds wrote:
You can often make things go faster by simplifying and streamlining the
code rather than trying to be clever and having a big footprint. Ask Keith
Packard about the X frame buffer code and this very issue some day.
The frame buffer code has
On Thursday 23 May 2002 04:37 pm, Leif Delgass wrote:
I've committed code to read BM_GUI_TABLE to reclaim processed buffers and
disabled frame and buffer aging with the pattern registers. I've disabled
saving/restoring the pattern registers in the DDX and moved the wait for
idle to the XAA
On Fri, 24 May 2002, Frank C. Earl wrote:
On Thursday 23 May 2002 04:37 pm, Leif Delgass wrote:
I've committed code to read BM_GUI_TABLE to reclaim processed buffers and
disabled frame and buffer aging with the pattern registers. I've disabled
saving/restoring the pattern registers in
I've committed code to read BM_GUI_TABLE to reclaim processed buffers and
disabled frame and buffer aging with the pattern registers. I've disabled
saving/restoring the pattern registers in the DDX and moved the wait for
idle to the XAA Sync. This fixes the slowdown on mouse moves. I also
On Sat, 18 May 2002, Felix Kühling wrote:
On Sat, 18 May 2002 11:30:28 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] wrote:
Did you have a 2D accelerated server running on another vt? The DDX saves
and restores its register state on mode switches, so it could be a problem
with the FIFO
OK, I finally committed my changes thus far as a checkpoint. I'm reading
BM_GUI_TABLE in the dispatch routine to see when we hit the hardware
pointer and wait once we reach it. So the dispatch is treating the
descriptor table as a ring, and it helps. There's still lots of places to
optimize
On 2002.05.18 15:40 Felix Kühling wrote:
On Sat, 18 May 2002 15:01:51 +0200
Felix Kühling [EMAIL PROTECTED] wrote:
For this test I compiled everything with gcc-2.95.4. I had a different
problem after compiling with gcc-3.0. I have to try that again and
check
for compile errors. The
On Sat, 18 May 2002 11:30:28 -0400 (EDT)
Leif Delgass [EMAIL PROTECTED] wrote:
Did you have a 2D accelerated server running on another vt? The DDX saves
and restores its register state on mode switches, so it could be a problem
with the FIFO depth or pattern registers being changed. Try
On Sat, 18 May 2002 15:56:00 +0100
José Fonseca [EMAIL PROTECTED] wrote:
Nice report ;-)
Thanks :)
Try with xfree-gdb (http://www.dawa.demon.co.uk/xfree-gdb/) to see if you
have better luck.
Yep, that gave better results. Since I have only one computer here and
the display turns black I
On Sat, 18 May 2002 18:26:52 +0100
José Fonseca [EMAIL PROTECTED] wrote:
I also have to start using another X server in a sep window cause having
to log out everytime I want to test is a PITA.
I'm not sure whether I get this correctly. Anyway, I have my 2D Xserver
running on vt7 and start
OK, I've checked in my changes and here's what I added:
The bus master test now uses the pci pool already allocated by dma_init
rather than creating another temporary one. It allocates the data buffer
from the pool, but we could change this to make it grab a buffer from the
freelist of
On Monday 11 March 2002 01:55, Frank C. Earl wrote:
On Sunday 10 March 2002 11:44 am, Jos? Fonseca wrote:
I really don't know much about that, since it must happened before I
subscribed to this mailing list, but perhaps you'll want to take a look
to the Utah-GLX and this list archives. You
A while back there was a problem with the Mach64 initialisation such that it
locked up after executing dma, can someone point at what the resolution to
that problem was and where things were patched so I can have a look at it ?
Thanks
Bob
___
On 2002.03.10 11:30 Robert Lunnon wrote:
A while back there was a problem with the Mach64 initialisation such that
it
locked up after executing dma, can someone point at what the resolution
to
that problem was and where things were patched so I can have a look at it
?
Thanks
Bob
I
On Sunday 10 March 2002 11:44 am, José Fonseca wrote:
I really don't know much about that, since it must happened before I
subscribed to this mailing list, but perhaps you'll want to take a look to
the Utah-GLX and this list archives. You can get these archives in mbox
format and also
On 2002.03.10 15:55 Frank C. Earl wrote:
On Sunday 10 March 2002 11:44 am, José Fonseca wrote:
...
Sorry for being silent for so long gang. Been, yet again, crushed under
with lovely personal business. I have started a new branch
(mach64-0-0-3-dma-branch), and I'm actually putting the
On Sunday 10 March 2002 04:36 pm, José Fonseca wrote:
I didn't fully understand the implications of above, but shouldn't the
direct access to the chip registers still be denied to clients?
Depends.
Looking at the gamma source code (I could be wrong, mind...) it appears that
the DRM is
On 2002.02.10 09:31 Gareth Hughes wrote:
...
These chips can read
and write arbitrary locations in system memory. For all chips that
have this feature, the only safe way to program them is from within
Which of the chips currently supported by DRI is more similar in this [DMA
programming]
On Tuesday 08 January 2002 04:12 pm, Leif Delgass and Manuel Teira wrote:
Happy New Year!
Hopefully for all, it will be a better one than the last...
Well, after the holidays, I would like to recover the development in the
mach64 branch. I started today to investigate the DMA stuff
Frank C. Earl wrote:
While we're discussing things here, can anyone tell me why
things like the emit state code is in the DRM instead of in
the Mesa drivers? It looks like it could just as easily be
in the Mesa driver at least in the case of the RagePRO code-
is there a good reason why
On Sunday 13 January 2002 11:50 pm, Gareth Hughes wrote:
While we're discussing things here, can anyone tell me why
things like the emit state code is in the DRM instead of in
the Mesa drivers? It looks like it could just as easily be
in the Mesa driver at least in the case of the
On Mon, 7 Jan 2002, Manuel Teira wrote:
Hello again. First of all, happy new year to everybody.
Happy New Year!
Well, after the holidays, I would like to recover the development in the
mach64 branch. I started today to investigate the DMA stuff because I think
that perhaps Frank is very
Hello again. First of all, happy new year to everybody.
Well, after the holidays, I would like to recover the development in the
mach64 branch. I started today to investigate the DMA stuff because I think
that perhaps Frank is very busy and he has no time to do this work. The DMA
problem was
On Wednesday 24 October 2001 01:54 am, [EMAIL PROTECTED] wrote:
a=readl(kms-reg_aperture+MACH64_BUS_CNTL);
writel((a | (31) )(~(16)), kms-reg_aperture+MACH64_BUS_CNTL);
same other code
works fine. Now why would this be ?
This could be caused by the same thing
58 matches
Mail list logo
