Announcement

Collapse
No announcement yet.

An LLVM Backend For the Raspberry Pi VPU

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by daemon32 View Post
    Huh, I read somewhere that it did have an MMU...
    People might have said that, but they either were talking about something else or were wrong . There's nothing that does a 4KB-granularity mapping between VPU virtual addresses and physical addresses, it just has to use contiguous physical memory for everything. (If there had been an MMU, the dynamic memory allocator on the VPU could have been quite a bit simpler.)

    And interrupts are the only reason communication from ARM -> QPU is slow?
    Hmm, I don't know whether ARM->QPU communication is actually slow, and I suppose interrupt handling latency might not even be an issue - the Linux VC4 driver seems to do most of its work directly in the interrupt handler and won't need to wait for the scheduler, so maybe it's not a problem and an RTOS wouldn't make much difference. I'm not aware of any other issues with accessing V3D from the ARM instead of from the VPU (though I'm not an expert on this stuff).

    I think the original VC4 software architecture (with the GL driver running on the VPU) is mainly determined by historical reasons - some chips had ARM cores that were much slower than the VPU, or didn't have an ARM at all, and some chips had a decent ARM but it wasn't wired up to the V3D block, so the GL driver was written to run on the VPU instead, and RPi reused that driver because writing a new one would be an enormous amount of work. But now that someone is being paid to do that work, moving the driver to the fast ARM seems like a better design.

    Comment

    Working...
    X