On Thu, 30 May 2002, José Fonseca wrote:
> 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
On Fri, 31 May 2002 02:30:11 +0200
Felix Kühling <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I reported lockups shortly after starting the Xserver with a gcc 3.0
> compiled drm module that triggered the strange permission problem. Now I
> tested it without loading the dri Xserver module in XF86Config a
Hi,
I reported lockups shortly after starting the Xserver with a gcc 3.0
compiled drm module that triggered the strange permission problem. Now I
tested it without loading the dri Xserver module in XF86Config and got
the same lockup. The following messages in XFree86.1.log indicate that
the probl
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 sys
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 hour
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 co
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 ha
Karl Rasche wrote:
>>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 walkin
> 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 mo
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:
> > > >
> > > >
On Thu, 2002-05-30 at 15:37, Keith Whitwell wrote:
> Michel Dänzer wrote:
>
> >>>Right, but do we check if there is room before feeding the FIFO
> >>>directly?
> >>>
> >>No, not from the kernel module. I think this has to change. But the only
> >>places where we potentially do it directly are
Michel Dänzer wrote:
>>>Right, but do we check if there is room before feeding the FIFO
>>>directly?
>>>
>>No, not from the kernel module. I think this has to change. But the only
>>places where we potentially do it directly are where we issue RADEON_WRITE's
>>-- I don't think we have to chec
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
> >
On Thu, 2002-05-30 at 15:27, Keith Whitwell wrote:
> 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
>
> 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, th
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
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 alr
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 strug
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
> > f
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 head
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 was wrong (but if yo
Looks like the sanity checker has paid off:
Bufs 5 Total emitted 7328 real changes 1962 (26.77%)
Total emitted per buf: 1465.60
Real changes per buf: 392.40
Bad nr verts for line_strip 1
Bad nr verts for line_strip 1
--> We're emitting one-vertex line strips somewhere, which the engine is know
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 thes
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
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 messag
On 30 May 2002 12:56:10 +0200
Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Thu, 2002-05-30 at 08:08, Felix Kühling wrote:
> > On 30 May 2002 00:25:08 +0100
> > "Sergey V. Udaltsov" <[EMAIL PROTECTED]> wrote:
> >
> > > Again and again I take snapshots, again "Permission denied" even for
> > > ro
On Thu, 2002-05-30 at 08:08, Felix Kühling wrote:
> On 30 May 2002 00:25:08 +0100
> "Sergey V. Udaltsov" <[EMAIL PROTECTED]> wrote:
>
> > Again and again I take snapshots, again "Permission denied" even for
> > root. What could this be? Can it be related to gcc 3.1 I use to build
> > the kernel m
On Thu, 30 May 2002 10:06:45 +0100
José Fonseca <[EMAIL PROTECTED]> wrote:
> Sergey and Felix,
[...]
> > > So I have the same permission problem and it only occurs with gcc 3.
> > :(( Does this mean gcc 3 sucks?:) Actually, transition from 2.96 to 3.1
> > was not easy - had to rebuild all c++ pro
> 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 som
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
Sergey and Felix,
I was already switching my Gentoo system to gcc 3.1 - I hope that in a day
I've recompiled most of the stuff I need -, and I'll start looking at this
as well.
On 2002.05.30 09:18 Sergey V. Udaltsov wrote:
> > mach64_state.c:682: warning: concatenation of string literals with
> 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
>
> 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 bein
33 matches
Mail list logo
