On Wed, Jun 05, 2002 at 11:18:15AM -0600, Jens Owen wrote:
> While looking at the DRI overhead, I got curious about x11perf results.
> Consequently, I tried a run, just to get a baseline, and segfaulted the
> server.
>
> This can be reproduced with:
>
> x11perf -seg100c2
>
> when the DRI is
On Wed, 5 Jun 2002, José Fonseca wrote:
> On 2002.06.05 20:34 Leif Delgass wrote:
> > On Wed, 5 Jun 2002, José Fonseca wrote:
> > > ...
> > >
> > > In _wait_ring you don't check if card is idle (and resume) so you could
> > > be forever waiting for free space space.
> >
> > I do see the problem
On 2002.06.05 20:34 Leif Delgass wrote:
> On Wed, 5 Jun 2002, José Fonseca wrote:
> > ...
> >
> > In _wait_ring you don't check if card is idle (and resume) so you could
> > be forever waiting for free space space.
>
> I do see the problem there, I was thinking that this couldn't be
> triggered
>
On Friday 31 May 2002 4:54 pm, Tim Smith scribed numinously:"
> On Friday 31 May 2002 4:12 pm, Keith Whitwell scribed numinously:"
>
> > Tim Smith wrote:
> > > Me too. Could this be a locking problem? There seem to be two
> > > contexts owned by the same PID in this case, and the
> > > LOCK_TEST_W
On Wed, 5 Jun 2002, José Fonseca wrote:
> On Tue, 4 Jun 2002, Leif Delgass wrote:
> > On Tue, 4 Jun 2002, Jose Fonseca wrote:
> >
> > > Leif,
> > >
> > > As I was restructuring part of the DMA submission code I realized that
> > > there is a fault in the NO_BATCH_DISPATCH path. You don't guarant
On Sun, Jun 02, 2002 at 06:14:08PM +0100, Michael wrote:
> > I'll happily test any patches, just send them my way.
>
> Ok, I'll post something later...
hmm, further playing around, I changed the CPWaitForIdle to use the
non-CP WaitForIdle so the looping in X is in user space not system,
removed
Jens Owen wrote:
>
> While looking at the DRI overhead, I got curious about x11perf results.
> Consequently, I tried a run, just to get a baseline, and segfaulted the
> server.
[...]
> I'm building the development branch from the XFree86 repository right
> now to see if that yields any differe
.
I don't know how long we'll manage to keep the MMIO stuff there. I'm not
very keen to support old code simultaneously, especially since there is no
report that DMA doesn't work.
José Fonseca
mach64-20020605.diff.gz
Description: GNU Zip compressed data
On Tue, 4 Jun 2002, José Fonseca wrote:
> Leif,
>
> As I was restructuring part of the DMA submission code I realized that
> there is a fault in the NO_BATCH_DISPATCH path. You don't guarantee
> that the card doesn't stop at any momment because you've chosen not
> check if a change in the las
While looking at the DRI overhead, I got curious about x11perf results.
Consequently, I tried a run, just to get a baseline, and segfaulted the
server.
This can be reproduced with:
x11perf -seg100c2
when the DRI is enabled.
Here is a stack trace from a static server built from the TCL branc
On Wed, 5 Jun 2002, Peter Soetens (Kaltan) wrote:
> On Tuesday 04 June 2002 18:53, you wrote:
> > Maybe you should start reading about advanced c programming
> > technics first? (Okay, Pascal will do the job as well.)
> > advanced here means programming with mutexes, semaphores,
> > interrupts,
Michel Dänzer wrote:
>
> On Wed, 2002-06-05 at 01:05, Jens Owen wrote:
> >
> > Have you seen any clear bugs when the server regenerates?
> >
> > After Linus asked the questions regarding locking optimizations for the
> > Radeon, I decided to explore the current policies in the Radeon driver.
> >
> Anybody want to swap me a voodoo[2-5] for an ATI Mach64 AGP?
I have a Voodoo3/3000 PCI that I do not use - I also have an ATI Mach64 AGP,
that I don't use either ;-)
I could lend you the Voodoo als long as it is necessary, if nobody has one
(I live in Germany and shipping even of some small gr
13 matches
Mail list logo
