Is there the possibility to support EXA for legacy S3 chips?

[Ville Syrjälä]

On Wed, May 27, 2009 at 05:50:51PM -0400, Alex Deucher wrote:
> On Wed, May 27, 2009 at 5:09 PM, Evgeny M. Zubok <evgeny.zubok at tochka.ru> wrote:
> >
> > I have made the first attempt to implement basic `Copy' and `Solid' EXA
> > functions in xf86-video-s3, but soon came to intention that EXA support
> > is not possible. Is there mistake in my thinking below?
> >
> > S3's Graphic Processor (S3 GP) is able to copy areas only in terms of
> > coordinates, i. e. it can copy rectangle from (src-x, src-y) to (dest-x,
> > dest-y) with width w and height h (Fig. 1). This method is used in XAA
> > ScreenToScreenCopy function. But S3 GP hasn't mean to copy offscreen
> > pixmaps in format presented on Fig. 2 to framebuffer, i. e. there is no
> > way to write the pixmap's offset and pitch directly into GP registers to
> > make subsequent copying. I looked up on the code of few other drivers
> > where EXA is implemented (ati, trident, mga) -- all these chips have the
> > possibility to write offset and pitch of pixmap into their GP.
> >
> > Although the method (by means of Pixel Transfer Register) exists to
> > upload pixmap from the system memory to S3's offscreen memory in
> > required format (Fig. 1) (I didn't try it), such offscreen memory
> > organization will not be understandable to the EXA offscreen memory
> > manager. Most probably this will follow to incorrect pixmap migration
> > and overwriting previously uploaded pixmaps.
> >
> > The objection above sounds like the judgement to EXA support in S3
> > driver. No?
> 
> Looks like no dice for EXA.  Fixed pitches, no offsets... ouch.

Why wouldn't it work if you just allocate everything using the same
pitch? Or does the allocator make some assumptions about the pitches the
hardware can handle?

-- 
Ville Syrjälä
syrjala at sci.fi
http://www.sci.fi/~syrjala/