> On 9 Feb 2016 03:27, "Mike" <michael.hel...@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" <mic...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev