PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote: 
> > Von: "Michel Dänzer" <michel at daenzer.net>
> > On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote: 
> > > > Von: "Michel Dänzer" <michel at daenzer.net>
> > > > On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote: 
> > > > > Michel Dänzer <michel at daenzer.net> writes:
> > > > > 
> > > > > > On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: 
> > > > > >> Michel Dänzer <michel at daenzer.net> writes:
> > > > > >> 
> > > > > >> > Have you tried smaller aperture sizes (uninorth_agp.aperture)
> > > > > >> > and/or radeon.test=1? (See commit
> > > > > >> > 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c)
> > > > > >> 
> > > > > >> Neither changes anything.
> > > > > >
> > > > > > How small aperture sizes have you tried?
> > > > > 
> > > > > 32M. With the old UMS driver 3D once worked fine ...
> > > > 
> > > > That doesn't necessarily mean much per se, as with UMS memory is
> > > > only statically mapped into the AGP GART once (so most of those
> > > > 32M are wasted at least most of the time), whereas with KMS it's
> > > > dynamically (un)mapped on demand.
> > > That may be a stupid question, but is it allowed (for a DRM client or
> > > whatever does the mapping) to change the content of a page mapped into
> > > the AGP GART or is it necessary to explicitly unmap the page, change
> > > its content and map it again?
> > 
> > The former.
> I know that the uninorth AGPGART driver does a cache flushing for newly
> mapped pages,

Ah, right, that probably explains why the map_page_into_agp change
doesn't make any difference.


> but is there any code in the driver that handles the former case (or
> isn't this necessary on PPC Macs)?

If by 'former case' you mean userspace modifying memory mapped into the
AGP GART, then no, this generally doesn't require special treatment on
PowerMacs. (Ignoring the potential issue mentioned by Ben in this
thread)


> > > I would say it's necessary to unmap the page first (sounds more like
> > > the pci_[un]map_page() approach) - at least when it should work with
> > > non-coherent architectures, too.
> > 
> > I'm afraid non-coherent platforms haven't really been a concern yet for
> > KMS, and always doing the above dance would probably have a significant
> > performance impact on coherent platforms.
> Are there any plans for a page flushing API? I suppose that wouldn't
> have such a big performance impact on coherent platforms (but probably
> an impact on the userspace API).

Not that I know of.

Note that this isn't necessarily the only possible approach for
addressing this problem. The driver knows which memory buffers are used
by a GPU command stream sequence, so it should be able to take any
measures necessary to ensure the device sees their contents as of when
the command stream was submitted.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer