forums.ps2dev.org

[TyRaNiD]

Given that most devices (if not all) are mapped to both IOP and EE addressing space what advantages could be gained from writing drivers for the EE instead of the IOP?

Certainly one of the main plus points of the IOP is it's modular system which lends itself well to device drivers but might the power of the EE be better suited to such devices as the SMAP and Firewire (if that is ever written).

Discuss :)

[ooPo]

Writing for the EE would get you access to all the nifty parts on the EE, like the vector units or IPU.

[mrbrown]

The main issue with drivers on the EE is that both device interrupts and DMA are always routed to the IOP. PS2/Linux gets around this by using both an interrupt relay module (intrelay.irx in TGE) and dma relay module (dmarelay.irx in TGE).

Sony took an interesting approach with the PS2/Linux USB driver, instead of relaying data packets using their dmarelay-type module, they instead allocate a chunk of IOP RAM for USB transfers, and do direct copies to and from the IOP transfer address using the 0xbc000000 mapping.

Another example of a split driver model in the game development world is Sony's eyetoy library, there is a IRX that communicates directly with the device and does initialization and other settings type stuff, and that IRX communicates with an EE eyetoy driver that decodes picture frames via the IPU and shows them on the screen.

IMO, it depends on the type of application. Although I don't have any hard numbers, I would imagine loading the IOP with too many high-speed device drivers would eat away at performance. And the fact that any devices using DMA (this would be HDD, SMAP, CDVD, USB, FireWire, SIO2) have to be relayed to the EE anyway, this adds SIF DMA into the equation. Relaying interrupts is also double the cost, because when the interrupt hits the IOP you have to trigger a SBUS interrupt on the EE.

One advantage of relaying DMA however is that you can eliminate SIF RPC if you do it right, which gets rid of the RPC "2-way" handshake required for every RPC transaction (EE sends RPC request to interrupt IOP, IOP sends result to interrupt EE).

As far as the "power of the EE" you mention, while the EE can certainly delve out buffers and satisfy requests faster than the IOP, you are still limited to max IOP speed because of the interrupt/dma thing :).

The IOP is coming along for the ride and you can't kick her off the back of the truck.

[nosense]

Depends on your focus really. If your main objective is to do really fast device IO fullstop, then maybe it's OK to use the EE. If on the other hand, the dev IO is to acheive some kind of ancillery function such as serve data etc to be used by some other EE application, then it makes sense to free up EE cpu time by offloading dev IO to IOP.
eg loader loads app over firewire & that should be fast & maybe argument exists for using EE (assuming it is actually faster). However, app then starts up & hopefully utilises the full glory of EE + co-pros' but still requires dev IO - makes sense to offload dev IO to IOP.
At the moment ppl are focussed on initial loading, but in the longer term, firewire/smap/hdd/etc drivers are a data pipe used by the application & it's the performance of the application that needs to be maximised.
You only need to improve dev IO throughput when it becomes the limiting factor. Prior to that, you just need to do it utilising given resources as efficiently as possible.