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 co
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
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
> > all
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 visualiz
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 g
>
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 b
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 j
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.
>
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 s
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 syst
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
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
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
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 h
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: 2[MB/f
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 reaso
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, th
On Saturday 25 May 2002 06:37 pm, David Willmore wrote:
> I'm new to the devel list--I got on to help test the new Mach64
> code. I don't have much time these days to contribute coding,
> but I can test. ;)
Everything is welcome- and your testing is appreciated. (Nice domain name,
BTW. I lik
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 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
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 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
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.
> > >
> >
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
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 se
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 cal
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 DM
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 cour
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 a
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 holdin
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
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,
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 pre
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 secu
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 ad
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.
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 regist
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 X
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
fixed
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
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
On 2002.05.18 18:02 Felix Kühling wrote:
> 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.
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
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
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 testing
without another X server running if you haven't already. Also, does
anything s
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 erro
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 problem was that the X server segfaulted on
> s
Hi,
I updated my DRI tree and recompiled everything. With glxgears, and
quake1 things work fine and the framerate has increased again. glxgears
went from 190 to 240 :). With quake2 and quake3 the Xserver locks up
before anything is drawn. I can kill the X-server with the secure access
sysrq key s
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 and
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 mapped
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 archive
On 2002.03.10 21:30 Frank C. Earl wrote:
> ...
>
> If you don't have issues with sending commands directly, you don't need
> to
> copy or map/unmap. You don't need special clear commands or swap
> commands,
> you only need to issue DMAable buffers of commands to the DRM engine for
> eventual sub
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 ta
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 puttin
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 fil
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
>
>
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
___
Dri-de
José Fonseca wrote:
>
> 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
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
programmi
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 th
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
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 be
El Mar 08 Ene 2002 22:12, Leif Delgass escribió:
> It sounded like Frank had written some code already (he mentioned being
> "halfway done" in early December). Frank, is your work in a state that
> could be commited to the branch so others could help finish it? If so,
> this might be a good pla
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 v
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 d
On Wed, 24 Oct 2001, Frank C. Earl wrote:
> On Wednesday 24 October 2001 01:54 am, [EMAIL PROTECTED] wrote:
>
> >
> > a=readl(kms->reg_aperture+MACH64_BUS_CNTL);
> > writel((a | (3<<1) )&(~(1<<6)), kms->reg_aperture+MACH64_BUS_CNTL);
> >
> > same other code
> >
> >
On Wednesday 24 October 2001 01:54 am, [EMAIL PROTECTED] wrote:
>
> a=readl(kms->reg_aperture+MACH64_BUS_CNTL);
> writel((a | (3<<1) )&(~(1<<6)), kms->reg_aperture+MACH64_BUS_CNTL);
>
> same other code
>
> works fine. Now why would this be ?
This could be caused by t
I am working with km v4l module (http://gatos.sf.net) and I have come
accross a strange issue with mach64 DMA engine. For some reason it would
not work unless I reset it using BUS_CNTL.
I.e.:
a=readl(kms->reg_aperture+MACH64_BUS_CNTL);
writel(a & (~(1<<6)), kms->reg_aperture+MACH6
68 matches
Mail list logo
