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@gmx.net
To: michael.heltne@gmail.com
Subject: Re: PowerPC agpmode issues
Date: Tue, 9 Feb 2016 12:52:15 +0100
CC: aneesh.kumar@linux.vnet.ibm.com; michel@daenzer.net; linuxppc-dev@lists.ozlabs.org; reinhard.boris@googlemail.com; bobby.prani@gmail.com

quoted

On 9 Feb 2016 03:27, "Mike" [off-list ref] 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?).

quoted

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... :-)

quoted

On 9 Feb 2016 02:41, "Michel Dänzer" [off-list ref] wrote:

quoted

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