PowerPC agpmode issues

[luigi burdo]

Mike and Gerhard, dont think the situation of the pcie powerpc is bettrer.but compared with last years with the new kernels and last xorg on a radeonhd 4650 i have an increase of performance about 250x ... example QuakeSpasm was gaving 640x480157fps on Radeon 4650... Now is 380 fps yes compared the old nvida 7800gtx on Osx  450 fps this results are less but for sure better than before.
The worst of last period im facing r600 radeon ring test errors and  i cant usewith gpu accel now only in fbdev the 5450 and 6570 that it was perfect working before.
Luigi

> From: gerhard_pircher at gmx.net
> To: michael.heltne at gmail.com
> Subject: Re: PowerPC agpmode issues
> Date: Tue, 9 Feb 2016 12:52:15 +0100
> CC: aneesh.kumar at linux.vnet.ibm.com; michel at daenzer.net; linuxppc-dev at lists.ozlabs.org; reinhard.boris at googlemail.com; bobby.prani at gmail.com
> 
> > 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
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20160209/d3bd7e92/attachment.html>