Howzit?
Thanks to all those who have been helping me, this has got done a lot quicker
than it otherwise would have, and the DRI site is still standing ;-).
Anyhow:
http://dri.sourceforge.net/site_update/
All comments, suggestions, requests are welcome.
Liam
it depends
---
I've been doing some more testing. With, and without, the commit_ring
patches, even in pci mode, I can get X to hang without too much effort
by firing up several glx demos and then x11perf. One of the glx programs
will hang holding hw locks in r128WaitForFrameCompletion() from
r128CopyBuffer().
On Thu, 2002-07-18 at 23:08, Jacek Rosik wrote:
> Michel Dänzer wrote:
> > On Wed, 2002-06-26 at 02:35, Jacek Rosik wrote:
> >
> >>BTW: Why in function radeon_emit_clip_rect
> >>(xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_state.c)
> >>line:
> >>/*
> >>OUT_RING( ((box->y
On Thu, 2002-07-18 at 18:20, Benjamin Herrenschmidt wrote:
> >AGP has become very stable here since the radeon driver doesn't update
> >the ring write pointer in ADVANCE_RING() but in the new COMMIT_RING().
> >Seems updating it 'too often' is no good, for whatever 'too often' may
> >mean.
>
> I
On Thu, 2002-07-18 at 21:29, Charl P. Botha wrote:
>
> On Thu, Jul 18, 2002 at 07:04:25PM +0200, Charl P. Botha wrote:
> > Thinking that the LockHeld semaphore which was added to i810_driver.c (as
> > well as i830) to prevent syncs when DriLock hadn't been called was relevant
> > (it was reported
Jacek Rosik wrote:
> Michel Dänzer wrote:
>
>> On Wed, 2002-06-26 at 02:35, Jacek Rosik wrote:
>>
>>> BTW: Why in function radeon_emit_clip_rect
>>> (xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_state.c)
>>> line:
>>> /* OUT_RING( ((box->y2 - 1) << 16) | (box->x2 - 1) );*/
Michel Dänzer wrote:
> On Wed, 2002-06-26 at 02:35, Jacek Rosik wrote:
>
>>BTW: Why in function radeon_emit_clip_rect
>>(xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/radeon_state.c)
>>line:
>>/*
>>OUT_RING( ((box->y2 - 1) << 16) | (box->x2 - 1) );*/
>>is conmmented? I think it's
Henry Worth wrote:
>
>
> BTW, I do see quite a few "128(0): Idle timed out, resetting engine..."
> being logged by r128_accel.c's R128WaitForIdle() routine when running
> x11perf with both the old and new drivers.
Tripped a different hang running xine in agp mode with XV dma disabled.
With xine
Dear list,
On Thu, Jul 18, 2002 at 07:04:25PM +0200, Charl P. Botha wrote:
> Thinking that the LockHeld semaphore which was added to i810_driver.c (as
> well as i830) to prevent syncs when DriLock hadn't been called was relevant
> (it was reported that this had caused hangs on VT switches on thos
Michel Dänzer wrote:
>On Thu, 2002-07-18 at 16:40, Keith Whitwell wrote:
>
>>Henry Worth wrote:
>>
>>>
>>I have no idea why there is a need for the RING_SPACE_TEST macro. It's
>>disabled in the r200 branch.
>>
>
>Besides, I've never hit the added code there.
>
Ok, I won't worry about that.
>>>
Michel Dänzer wrote:
>On Thu, 2002-07-18 at 09:47, Henry Worth wrote:
>
>>Henry Worth wrote:
>>
>>>Digging thru the X logs, I see that agp is failing to map the ring
>>>buffer with
>>>this drm module. It does with kernel module built from BenH's linuxppc
>>>dev
>>>tree, but I haven't tried the
On Wed, Jul 17, 2002 at 11:18:59PM +0200, Charl P. Botha wrote:
> I think I'm going to give 2.5.x (with the 2.4 IDE backport, no sense in
> throwing away all my data) kernel a shot to see whether updates to agpgart
> make any difference.
This experiment wasn't successful either. I tried with num
On Mon, 2002-07-15 at 23:13, Steven Walter wrote:
> I recently bought a Radeon 7500 64MB DDR (lovingly called a "QW"), and
> have had no luck with the DRI cvs trunk. 3D acceleration /does/ work,
> however, with xfree86 4.2
>
> The problem is, whenever I run a 3d app, I get a segmentation fault.
>AGP has become very stable here since the radeon driver doesn't update
>the ring write pointer in ADVANCE_RING() but in the new COMMIT_RING().
>Seems updating it 'too often' is no good, for whatever 'too often' may
>mean.
I hate that. It should be fully stable or I would consider it
unuseable :(
On Thu, 2002-07-18 at 16:40, Keith Whitwell wrote:
> Henry Worth wrote:
> >
> > Michel,
> >
> > How do these changes for r128 COMMIT_RING look? With these I can run
> > concurrent xine and glx programs in pci and agp mode with XV dma
> > disabled.
> >
> > With XV dma enabled, in both pci and ag
Henry Worth wrote:
>
> Michel,
>
> How do these changes for r128 COMMIT_RING look? With these I can run
> concurrent xine and glx programs in pci and agp mode with XV dma
> disabled.
>
> With XV dma enabled, in both pci and agp mode, I can run xine for some
> time without any hangs. But startup
Warning
Unable to process data:
multipart/mixed;boundary="=_NextPart_000_00D2_48A01D1A.A2548C67"
On Thu, 2002-07-18 at 09:47, Henry Worth wrote:
> Henry Worth wrote:
>
> >
> > Digging thru the X logs, I see that agp is failing to map the ring
> > buffer with
> > this drm module. It does with kernel module built from BenH's linuxppc
> > dev
> > tree, but I haven't tried the dri CVS before,
Henry Worth wrote:
>
> Digging thru the X logs, I see that agp is failing to map the ring
> buffer with
> this drm module. It does with kernel module built from BenH's linuxppc
> dev
> tree, but I haven't tried the dri CVS before, so I don't know yet if
> it even works
> without the COMMIT_RIN
Henry Worth wrote:
>
> Michel,
>
> How do these changes for r128 COMMIT_RING look? With these I can run
> concurrent xine and glx programs in pci and agp mode with XV dma
> disabled.
Digging thru the X logs, I see that agp is failing to map the ring
buffer with
this drm module. It does with ke
20 matches
Mail list logo
