On 30 Jan 2002, Michel [ISO-8859-1] Dänzer wrote:

> On Mon, 2002-01-28 at 15:30, Vladimir Dergachev wrote:
> >
> >
> > On 28 Jan 2002, Michel [ISO-8859-1] Dänzer wrote:
> >
> > > On Mon, 2002-01-28 at 10:00, Vladimir Dergachev wrote:
> > > >
> > > >
> > > > On 28 Jan 2002, Michel [ISO-8859-1] Dänzer wrote:
> > > >
> > > > > On Mon, 2002-01-28 at 04:54, Davor Buvinic wrote:
> > > > > >
> > > > > > Yes, running glxgears cause the movie player to crawl and if I start to 
>move
> > > > > > or resize their windows X crashes.
> > > > > >
> > > > > > The movie player is MPlayer, today cvs.
> > > > > >
> > > > > > Here is my log file from X. As you can see, at the end of the file the
> > > > > > following messages appears:
> > > > > >
> > > > > > [...]
> > > > > > (II) R128(0): StopVideo
> > > > > > (EE) R128(0): Idle timed out, resetting engine...
> > > > > > [...]
> > > > >
> > > > > I have an idea what the problem could be. The Xv code still uses direct
> > > > > register access, even when the CCE is running. That's exactly what we
> > > > > want to avoid, because it can crash the chip. :)
> > > > >
> > > > > I probably won't have time this week to work on a solution but I suggest
> > > > > you try either shutting down the CCE before accessing registers or
> > > > > adding new Xv functions which use the CCE for register access (à la the
> > > > > CCE accel functions). I'd prefer not shutting down the CCE at any rate.
> > > > >
> > > >
> > > > Yes, that's what happens. I do think we need to shutdown CCE because in
> > > > some case we want to read registers - and not only write. The short term
> > > > solution would be to use XAA->Sync() instead of WaitForEngineIdle because
> > > > WaitForEngineIdle does not guarantee the card is quiscent in CCE mode.
> > >
> > > Sounds like the correct fix, except I don't even see 'WaitForEngineIdle'
> > > in my trees - is that a GATOS novelty? :)
> >
> > Ahh.. sorry it's called XXXXXWaitForIdle :)) WaitForEngineIdle is how its
> > called in ATI sample code.
>
> Okay, but those aren't either in the Xv code I have, (where) have you
> added them?

http://gatos.sf.net/ - they were there last time I submitted a patch.. but
it did not get in. Just to make sure I am not pulling your leg.. Yep, they
are there: search for  R128WaitForIdle(pScrn) function.

>
> > Btw, while I've been sleeping I thought how we could get CCE support into
> > Xvideo. The thing I am really against is duplicating code for case with
> > CCE  and without.
>
> Very much agreed. Eliminating that would also do the 2D acceleration
> much good, where a lot of functions are exact duplicates for both cases.
>
> > So, I thought, what about having "Software CCE" ? I.e. always use CCE
> > commands except that in case when dri driver is not availabe emulate
> > it. I am fairly certain emulating indirect buffer and 2d commands
> > would be pretty easy.
>
> I think that's taking it too far (CCE commands are mostly normal
> register writes or complex commands which can be hard to translate into
> normal register access), but R128WaitForFifo() and OUTREG() shouldn't be
> hard to modify such that they use BEGIN_RING(), OUT_RING_REG() and
> ADVANCE_RING() for the CCE case?
>

Yes, but I would much rather have everything look like CCE, but use
OUTREG/INREG when not available. The reason is that

  a) CCE is really the perfomance case
  b) It might turn out that emulating CCE in software is faster then usual
     OUTREGs
  c) This paves the way for PIO 3d support (i.e. when DMA is not available
     for some reason)
  d) this sounds cool
  e) provides reference implementation.. to check cce behaviour against
  f) the real problem is not outregs in the code, but INREGs - we'll need
     to make them CCE aware anyways
  g) CCE code is actually _cleaner_ than OUTREGs. I know I looked.

                       Vladimir Dergachev

>
> --
> Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
> XFree86 and DRI project member   /  CS student, Free Software enthusiast
>


_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to