On 30 Jan 2002, Michel [ISO-8859-1] Dänzer wrote:
> On Mit, 2002-01-30 at 10:32, Vladimir Dergachev wrote:
> >
> > On 30 Jan 2002, Michel [ISO-8859-1] Dänzer wrote:
> >
> > > > 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'm not sure it's so easy BTW. Have you looked at what CCE commands are
> available? I wouldn't want to implement a software emulation, but if you
> want to, have fun. :)
Yes. The fact is you can either DMA them up to CCE engine or write them
directly into the FIFO.
>
> > > 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
>
> How? The CCE doesn't do anything besides programming registers, does it?
Because, for example, we are batching up register transfers.
>
> > c) This paves the way for PIO 3d support (i.e. when DMA is not available
> > for some reason)
>
> Why would one want that? No DMA means no DRM means no DRI.
I heard AMD Irongate has problems with DMA and Radeons. DRM still works
fine as far as resource control is concerned.
>
> > d) this sounds cool
> > e) provides reference implementation.. to check cce behaviour against
>
> I don't see the use of this either.
>
> > f) the real problem is not outregs in the code, but INREGs - we'll need
> > to make them CCE aware anyways
>
> Are you sure that's a problem at all? IIRC the DRM code reads registers
> without special precautions about the CCE, but I don't have time to
> check right now.
This depends on which registers you are reading. Some can be read all the
time, but some are not. Regardless, many INREGs depend on previous OUTREGs
having actually made it to the hardware.
Vladimir Dergachev
>
> > g) CCE code is actually _cleaner_ than OUTREGs. I know I looked.
>
> I know I've written some. :)
>
>
> --
> 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
>
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
