Pegasos2 with RadeonHD/RX via bridge

@joerg
Yes I know, maybe my wording was not clear. What GPL prevents is one party turning GPL software into closed source software which is what I really meant by "commercial code", so maybe that's what causes misunderstanding. BSD license has no such restriction so somebody can take it and use it in part or change it and make it closed source, they only cannot claim they wrote it and have to keep copyright messages to acknowledge original developers. GPL also requires to keep the sources free and available for everybody and not use it in code that does not allow the same. So when you substitute commercial code with closed source code that's what I meant but failed to describe properly.

By the way it's not the GPL code that's sold commercially because the code itself is freely available (and cannot be charged more than the fair amount needed to transfer it) but additional services using that code like making distros or providing services based on that code and so on. But GPL software can be developed commercially for sure.

@kas1e

Quote:
I think you should only execute config-l@ once, not twice. When you execute it the second time it takes the value that the first execution left on the stack (the result you're trying to see) as the address to report on, which is not what you want (and may be why you're getting strange results). You should just do:


Quote:
Good point. Forth itself is decimal by default, but OpenFirmware may not be. The value '646011AB' is clearly in hex, so the number '16' is probably taken as hex as well. You could try something like:


If you get 13 (the value 19 in hex) then the numbers are being interpreted as decimal. If you get 1F then they're being interpreted as hex.

@msteed
Quote:

It's strangely return 0, does not matter where i am in : in /pci/ , or in /pci/pci@7 (in bridge), see:



At first i think that maybe it's exactly issue in bridge, but then the same happens if i go to any pci based directory, always zero..

Quote:

Thanks for point, it is Hex:

@kas1e
With hex you have to useinstead of 16 to get the first BAR.

@Joerg
Same 0 as expected :( (there should be values anyway, even with wrong 16). Question is : what BAR we tried to read with this "16", i mean first BAR of what, if it the same does not matter in what directory (be it root /pci, or /pci/pci@7, or any other pci) happens to be. Like it just general offset of 16 of whole PCI thing, but we need first BAR of the card behind the bridge : how to say/calculate that ?

@Sailor
It takes a while, but i at last received this AGP-to-PCI(e) adapter we talk about on the first page from there: https://www.ebay.com/itm/125723908233

Takes 2 just in case, but then i probably will test them once Hans deal with casual bridge , as there are changes that with this kind of adapters and tests around it my pegasos2 will burn and die, so firstly want to be able to finish testing of what Hans is working on, and then will test this adapter.

@All
Hans progressing pretty well with replacing non-working-with bridges RTAS way os4 kernel uses for pegasos2, to the direct PCI reading/writing way, and currently there few bits to fix before it can come up with something, but at least we surely have correct addresses of video memory now, things which remain is to fix some registers reading, and then there high chance it will work! Rise of Frankenstein !

@kas1e
Quote:It's not PCIe but PCI-X!

@joerg
Right, but i mean to put pci2pcie bridge in this adapter, so to use agp to double speed (as agp in peg2 its pci but not on 33, but on 66)

@All
Tried this adapter in end of all : https://www.ebay.com/itm/125723908233

Tried it with both bridges : pericom and pex ones, and in both cases in firmware when i go to the pci@C0000000 (agp area) all i have is pci@8 , properties on which show that this is bridge (so both bridges detects correctly via adapter), but , both didn't see a graphics card in.

One time i was lucky (probably was some bad attachment of adapter or something), and instead of just pci@8 in pci@C0000000, i did have about 20 different pci's (pci@1, pci@2, pci@3, etc), in which card were detected ! (both audio and video parts). But that was just one time, and does not matter how hard i tried to reproduce it, i always can't. While when bridge just in pure PCI without adapters all fine and detects by firmware fine.

So probably conclusion is : this missed "lock" signal is what made it not works. The one time detecting was probably some bug in this lock signal handling or something.

@All

Did i understand correctly, that on pegasos2 we have PCI slots which is 32-bit ones on 33MHZ, and an AGP one which in reality the same PCI 32-bit one, just not on 33MHZ, but on 66 MHZ, and that all difference ?

If so, then did i get it right, that maximum limit of the PCI bus is 133.33 MB/s , while AGP (in our case PCI 66MHZ one) is 266 MB/s ? I.e. with PCI to PCIe bridge, we can only reach the limits of the PCI bus, which is 133 mb/s ?

What i mean, that i tested for now via gfxbench my Radeon9250 in AGP (so 32bit PCI 66mhz one) slot, and have those results:


Copy from RAM to VRAM:
Transfer size: 16296960 bytes
Src: 0x63c3f000, Dest: 0xc27a4160
copy32: 105.892 MiB/s (took 0.146772 seconds)
copy64: 107.069 MiB/s (took 0.145159 seconds)
copy64f: 135.885 MiB/s (took 0.114376 seconds)
copy64x2: 107.573 MiB/s (took 0.144479 seconds)
copy64fx2: 134.772 MiB/s (took 0.115321 seconds)
copy64fx2PF: 141.174 MiB/s (took 0.110091 seconds)
copy64fx4PF: 140.885 MiB/s (took 0.110317 seconds)
useMemcpy: 53.291 MiB/s (took 0.291645 seconds)
useExecCopyMem: 53.431 MiB/s (took 0.290878 seconds)
copyToVRAM: 207.152 MiB/s (took 0.075027 seconds)
WritePixelArray: 216.664 MiB/s (took 0.071733 seconds).


As far as i can see there, only WritePixelArray almost hit the limit of our AGP (216 mib = ~226mb, while limit is 266). But copy32, copy64 and all that are 2 times slower than a limit.

Is it mean Radeon9250 just can't reach AGP's bus maximum then in some cases ?


Then:

Copy from VRAM to RAM:
Transfer size: 16296960 bytes
Src: 0xc27a4160, Dest: 0x63c3f000
copy32: 37.399 MiB/s (took 0.415567 seconds)
copy64: 35.307 MiB/s (took 0.440196 seconds)
copy64f: 49.172 MiB/s (took 0.316077 seconds)
useMemcpy: 36.144 MiB/s (took 0.429999 seconds)
useExecCopyMem: 35.728 MiB/s (took 0.435004 seconds)
copyFromVRAM: 50.216 MiB/s (took 0.309504 seconds)
ReadPixelArray: 48.550 MiB/s (took 0.320125 seconds).


This one absolutely not hit the limits of AGP, as all the values in 5 times less that the AGP limits.

Is it again, because of Radeon9250 which can't reach AGP limits, or, it's just AmigaOS itself and it's kernel/driver/graphics.library cause issues there ?


Basically, if i got it right, with the PCI bridge in PCI (33mhz) slot we can reach at maximum with does not matter what graphics card we will use, a WritePixelArray of ~130MIB/s maximum , but then, copy from VRAM to RAM can be or the same at worst, or faster till 130mb/s in all tests, as even with Radeon9250 they didn't hit the limits.

Did i understand that all correctly ?

@kas1e

Reads are slower because they involve sending a request to the card, and then receiving the response (i.e., the returned value) from the card. This is inherently slower than shoveling data to the card.

DMA transfers can reduce the overhead by sending data in large blocks, so you need much fewer requests.

Hans

@kas1e
Quote:If you have a G4 CPU WritePixelArray and useExecCopyMem use AltiVec transferring 128 bits at a time, copy64f the FPU with 64 bits at a time, copy64 probably 2 * 32 bit integers and copy32 32 bit integer accesses.
AFAIK copyToVRAM and copyFromVRAM use AltiVec as well.
Each access to VRAM has PCI overhead, more bits transferred per access results in faster speeds.
The useMemcpy and useExecCopyMem results are much slower than they should be, but I don't know what the problem is.

@Hans
Quote:On Classic Amigas, AmigaOne and Pegasos2 there is no OS DMA copy (graphics (Read|Write)PixelArray(), exec CopyMemQuick(), etc.), only Sam4x0, X1000, X5000 and maybe A1222 have DMA based copy functions.
AFAIK GART is disabled in your drivers on AmigaOne and Pegasos2 as well, therefore no DMA at all.

Depending on the CPU the OS copy functions may use AltiVec on AmigaOne and Pegasos2, but for gfx card VRAM accesses that can only be about twice as fast as FPU based copy functions, if at all.
The DRAM read part of an AltiVec based copy between DRAM and VRAM should be more than twice as fast as a FPU one, but DRAM writes shouldn't make a difference (using DCBA or DCBZ with FPU writes is about the same speed as AltiVec writes using the streaming instructions).