I've attempted some rather pathetic rate-adaption to make everything slow
down when the FIFO gets full. It utterly murders performance but it did
prevent the lockup from occurring. I modified ADVANCE_RING to take a
parameter containing a Wild-Ass-Guess of how many commands were being
mach64_state.c:682: warning: concatenation of string literals with __FUNCTION__ is
deprecated. This feature will be removed in future
Yes. I noticed this doo
But it's only warnings.
I think so.
(II) ATI(0): [drm] loaded kernel module for mach64 driver
(II) ATI(0): [drm] drmSetBusid
On Thursday 30 May 2002 9:15 am, Keith Whitwell scribed numinously:
I've attempted some rather pathetic rate-adaption to make everything
slow down when the FIFO gets full. It utterly murders performance but
it did prevent the lockup from occurring. I modified ADVANCE_RING to
take a
I conclude from this that writing the ring tail register causes the card to
fetch all the commands up until that point and feed them to its FIFO, which
may fill it... It's certainly possible for the FIFO to go from 64 slots
free to 0 in one ioctl...
...so maybe what we need is some
On Thursday 30 May 2002 5:55 am, Michael scribed numinously:
On Thu, May 30, 2002 at 04:10:14AM +0100, Michael wrote:
Now X c r a w l s at this point, but switching back to q3 you can play
quake, frame rates seem fine, with just the chattering of continual
*Error* out of fifo messages
So, I've been writing a sanity checker for the radeon dma stream. All going
nicely found one stupid bug already.
One thing it does is keep track of values emitted to each register to see
if/when they actually change (as opposed to just emitting the old one again on
top of itself).
I've had
From: Keith Whitwell [EMAIL PROTECTED]
Date: Thu, 30 May 2002 12:59:23 +0100
I haven't proven whether these are all restore-context changes, or if some
additional bogus statechanges are emitted later on. Either way, it's easy to
see room for improvement...
In viewperf these
Michael wrote:
On Thu, May 30, 2002 at 12:59:23PM +0100, Keith Whitwell wrote:
So, I've been writing a sanity checker for the radeon dma stream. All
going nicely found one stupid bug already.
I'm struggling to see what the dyslexic bug is? It just looked like one of
the header files
On Thu, 2002-05-30 at 11:24, Keith Whitwell wrote:
I conclude from this that writing the ring tail register causes the card to
fetch all the commands up until that point and feed them to its FIFO, which
may fill it... It's certainly possible for the FIFO to go from 64 slots
free to 0
Michael wrote:
On Thu, May 30, 2002 at 01:59:31PM +0100, Keith Whitwell wrote:
Michael wrote:
On Thu, May 30, 2002 at 12:59:23PM +0100, Keith Whitwell wrote:
So, I've been writing a sanity checker for the radeon dma stream. All
going nicely found one stupid bug already.
I'm struggling
Michel Dänzer wrote:
On Thu, 2002-05-30 at 11:24, Keith Whitwell wrote:
I conclude from this that writing the ring tail register causes the card to
fetch all the commands up until that point and feed them to its FIFO, which
may fill it... It's certainly possible for the FIFO to go from 64
Yeah, drivers/ati/radeon_reg.h says that, but the kernel uses
radeon_drv.h, which has 0x1c50?
So you're still emitting to 0x1c50, which is either fine and it always
has been, or it's still buggy.
OK, I've gone back and looked at the docs and the radeon_reg.h value is
incorrect, the
On Thu, May 30, 2002 at 02:21:42PM +0100, Michael wrote:
On Thu, May 30, 2002 at 01:59:31PM +0100, Keith Whitwell wrote:
Michael wrote:
On Thu, May 30, 2002 at 12:59:23PM +0100, Keith Whitwell wrote:
So, I've been writing a sanity checker for the radeon dma stream. All
going nicely
On Thu, May 30, 2002 at 02:32:10PM +0100, Alan Hourihane wrote:
On Thu, May 30, 2002 at 02:21:42PM +0100, Michael wrote:
On Thu, May 30, 2002 at 01:59:31PM +0100, Keith Whitwell wrote:
Michael wrote:
On Thu, May 30, 2002 at 12:59:23PM +0100, Keith Whitwell wrote:
So, I've been
Sounds like you've got the destination pitch set incorrectly, at least.
Turns out it was source pitch. Thing are behaving much better now, I'm
sucessfully blitting from mmesa-mgaScreen-buffers.
But, it seems like i'm just re-mmapping the dma buffers and walking all
over them. Would it be more
Hi,
I tried the tcl-0-0-branch from DRI cvs (downloaded just some hours ago) and
so far 3D works much better than with the old drivers. It's a ATI Radeon QD
(AGP) according to X's logfile.
However the text console is totally messed up. The cursor is blinking
somewhere in the lower right
Leif,
On 2002.05.30 02:02 José Fonseca wrote:
... Tomorrow I'll take a look more carefully to see if I find anything
suspicious. ...
I've been analyzing the diff very carefully and what I've found so far are
just some details which can be taken care later (i.e., no bugs sorry) :
- This
Small update:
Using the old kernel module
[drm] Initialized radeon 1.2.0 20010405 on minor 0
does not produce the problem. The TcL code gets deactivated though.
Bye
On Thursday 30 May 2002 19:34, Oliver Feiler wrote:
Hi,
I tried the tcl-0-0-branch from DRI cvs (downloaded just some hours
On Thu, 2002-05-30 at 13:22, Felix Kühling wrote:
When I started the Xserver it locked up after the first few 2D
operations while loading the window manager. But I could kill it with
the secure access key. I didn't see anything suspicious in XFree86.1.log
or the syslog at the
19 matches
Mail list logo
