PowerPC agpmode issues

Gerhard Pircher gerhard_pircher at gmx.net
Tue Feb 9 22:52:15 AEDT 2016


> On 9 Feb 2016 03:27, "Mike" <michael.heltne at gmail.com> wrote:
> Ok, so its quirks to be added then? Something not implemented in KMS
> that was in UMS?
> Reports are that the same issue exsist on PPC Amiga Ones with a VIA
> chipset, and the Pegasos 2 with the Artica s chipset, i posted a
> mail from detailiing that.
Just to avoid some confusion:
Old long story short: the issues for AmigaOnes and the Pegasos _1_ with
ArticiaS northbridge and VIA southbridge are that:
1. the AGP controller corrupts data transfers in AGP mode (also depending
on the AGP HW request queue size). So there is no official AGP driver that
would require radeon.agpmode=-1. The microA1 is supposed to have a fix
for this HW data corruption, but I yet have to dig out my ArticiaS AGP
driver code for some test runs...
2. At least the AmigaOne with ArticiaS chip need non-coherent DMA
allocations and/or proper cache flushes to avoid corrupted DMA transfers.

Nonetheless I had DRI1 working _only_ on my A1SE under Debian Squeeze (i.e.
glxgears could run on the desktop with hardware acceleration), but DRI2
with its very dynamic GART mapping is a no-go on every first-gen AmigaOne
machine, even if the GART driver test (radeon.test=1) runs through in
PCIGART mode (could it be that it uses a more or less static GART mapping
for the test?).

> Sure that might be it, but i get different results trying agpmode=1-2-4,
> 2 gave a noisy screen before the hard crash. i find it rather impossible
> to debug at all as the crash happens so fast no logs seem to be written..
> I think i would need serial...
> I'd personally love nothing more then to see support restored and a
> default as expected working condition ought be the minimum requirement.
> I use a powerbook a1106, 5,6. With a 5,8 on the way. Those are the last
> two revision powerbooks in the 15" series. In swrast they become useless,
> impossible to use for any productivity. Most people trying to use linux
> on ppc for personal use come in macs, with the exception of the Amiga PPC
> crowd now running their amcc 440/460ex or e600 based x500/5000, all of
> which have of course pci-e more cores and more threads. Yet struggle even
> with regressions left and right to keep up with the single core performance
> of the G4's. Sure it's pushing 10 years , but it's the only alternative
> if one wishes to remain mobile.
swrast definitely isn't fun on 10 years old PPC machines. Current Firefox
is already slow enough on these machines... :-)

> On 9 Feb 2016 02:41, "Michel Dänzer" <michel at daenzer.net> wrote:
> > On 08.02.2016 22:28, Mike wrote:
> > Certainly 750~800 fps in glxgears vs 3000+ in debian squeeze, i cant
> > bring myself to say that it's an acceptable situation no matter how
> > tired i am of the problem knowing how well the setup could do. It's
> > clear that the implementation is broken for everything but x86, [...]
> 
> Why is that? It was working fine on my last-gen PowerBook. AFAIK Darwin
> / OS X never used anything but a static AGP GART mapping though, so it
> seems very likely that the issues with older UniNorth revisions are
> simply due to the hardware being unable to support the usage patterns of
> modern GPU drivers.
> 
> That said, if you guys have specific suggestions for a "proper"
> solution, nobody's standing in your way.
I have to admit that I lack the knowledge of the inner workings of the
TTM/radeon code (and its TTM AGP backend) to do any useful work here.
I was hoping that the TMA DMA allocator could be of any help at least for
non-cache coherent machines given that (IIRC) ARM is using it together
with the nuoveau driver on the TEGRA platform, but I guess that would need
some modifications also on the powerpc architecture side (maybe a new
non-coherent DMA allocator that is not limited to 2M virtual address space
for mappings). Thus I guess a lot of things could be improved/fixed, but
nowadays Linux code doesn't seem to be something for the "occasional hobby
hacker". :-)

regards,
Gerhard


More information about the Linuxppc-dev mailing list