Mon, 15 Jun 2026 08:13:25 +0000
Thanks very much for this Andrew. I am reassured.
Pi4 CM4 V3D Driver with MESASun, 14 Jun 2026 21:15:56 +0000
Yep, Cam’s absolutely right there – that was very much on the “to-do” list in terms of trying to get some consensus on compatibility for any release for Iris. Again, part of the reason why we stuck to Iris 1.x for now.
Building RISC OS components with GCC using DockerSun, 14 Jun 2026 18:05:37 +0000
Or, I guess, someone could talk to them about it and see if submitting a PR would be welcome?
As mentioned by Cameron, most of the changes are a) from people affiliated with ROOL and b) already in the gitlab.
The thing that might be a “little off” from the current ROOL’s gitlab is the Docker and script part, which might be put in as a “new tooling”, or as a separate portion of the gitlab source tree. So it’s mostly for ROOL to figure out what would be the best approach for the integration, and I am sure, afterwards Cameron would be very happy to create all the necessary PRs and merge it in.
However, it may also be that ROOL wants to keep GitLab repo pure RISC OS only, in which case the integration might not be of ROOL’s interest, given Docker would require a different platform.
Pi4 CM4 V3D Driver with MESASun, 14 Jun 2026 17:57:25 +0000
I’d also like to point toward this thread about the previous OpenGL implementations and the lack of a common interface between them – IMHO that’s one of the biggest things holding back OpenGL on RISC OS, and is worth keeping in mind when writing a new implementation: https://www.riscosopen.org/forum/forums/2/topics/19417
Pi4 CM4 V3D Driver with MESASun, 14 Jun 2026 17:43:34 +0000
Martin – might be worth talking to Lee Noar re Iris. For Iris “2.0” he has ported Mesa and some software driver stuff, although we’ve been focussing on Iris 1.0 for now. Recent WebKit builds rather assume OpenGL/Mesa-based graphics acceleration, so if you’re exploring those avenues, it might be worth keeping in touch with Lee to see if you can bolt things together.
Also – fascinating project and nice work so far! Probably should have started with that :)
On/Off keySun, 14 Jun 2026 17:35:05 +0000
The on-off LED is software controlled on Pinebook Pro, so unless an OS loads, it won’t illuminate.
The most common situation is that (for example) no micro-SD card is present on a dual-boot (RISC OS / Linux) unit, and so it turns on (at a hardware level) but doesn’t initialise anything because there’s no OS. Therefore the LED doesn’t turn on, nor the screen. The computer is “on” but is apparently lifeless (but drains the battery).
The solution to this (assuming the battery is still charged) is to connect power and let it charge for a bit, then press and hold the power button for 10 seconds which forces it “off”, then ensure the OS card is present/re-seated, then press-hold for 1-2 seconds which turns it back on.
My guess would be that you’ve simulated the above behaviour by accident.
I believe something similar can happen if the battery is fully discharged too, which is why I recommended having the mains connected.
If it is a RISC OS only unit booting from the eMMC, the chances of this occurring are slimmer, but it could have still run out of battery and been left in an undeterimed power state.
A general maintenance thing would be to ensure that the SD card is re-seated periodically and clean (if dual booting), and similarly inside the computer for the eMMC (I have known the eMMC come loose very occasionally – it is a push-fit connector). I’d probably only go inside if you’re convinced there is a problem, though.
Building RISC OS components with GCC using DockerSun, 14 Jun 2026 16:02:29 +0000
Or, I guess, someone could talk to them about it and see if submitting a PR would be welcome?
Most of the changes are already in merge requests, many of which are authored by people affiliated with ROOL. The scripts I posted are to simplify the process of setting everything up instead of having to apply all of the changes manually.
A full list of modified components is in this file – all of them had open merge requests when I last checked: https://github.com/ccawley2011/docker-riscos-build/blo…
Building RISC OS components with GCC using DockerSun, 14 Jun 2026 15:33:26 +0000
Hopefully ROOL will notice and add more support for the GCC building on GitLab.
Or, I guess, someone could talk to them about it and see if submitting a PR would be welcome?
Building RISC OS components with GCC using DockerSun, 14 Jun 2026 15:17:49 +0000
Nice work Cameron! Hopefully ROOL will notice and add more support for the GCC building on GitLab.
Pi4 CM4 V3D Driver with MESASun, 14 Jun 2026 14:14:46 +0000
Looking forward to this being released.
Great to see projects taking advantage of the built in capabilities that the latest systems, that RISC OS can run on, have.
Pi4 CM4 V3D Driver with MESASun, 14 Jun 2026 12:38:42 +0000
This project lets RISC OS use the Raspberry Pi 4’s built-in graphics chip to
2D/3D Accelerate on screen – Like Never before.
WHAT WORKS TODAY
On real Pi 4 / CM4 hardware, the graphics chip now:
The render pipeline loads each tile from a source buffer and stores it to a destination,
copying the whole image with no CPU involvement and no shaders. It’s the clear pipeline plus a single LOAD_TILE_BUFFER_GENERAL,
exposed as both the V3D_Blit SWI (&5A2D0) and the *V3DBlit command.
M0: map register windows, power+clock via firmware mailbox, read/decode IDENT.
M1: page table + V3D MMU, buffer objects mapped into GPU virtual memory.
M2: submit a bin+render control list and wait for completion.
The SUBMIT + FENCE path is complete and exact (ported from v3d_sched.c,
poll-based on V3D_CTL_INT_STS). What remains is encoding the CLE packet
BYTES of an actual control list – see “the M2 gap” below.
M3 – display path (testable without the GPU):
c.display wraps a BO as a RISC OS 32bpp sprite (area+header at the front,
pixels after) and plots it with OS_SpriteOp. v3d_fb_create lays out the BO
so the GPU renders straight into the pixel region; v3d_fb_show plots it.
*V3DShow fills the pixels from the CPU and displays – so the whole display
path can be validated on the Pi before the clear CL works.
Roadmap:
M0 power up + read IDENT DONE
M1 BO allocator + V3D MMU page table DONE
M2 submit bin+render CL + fence DONE – *V3DClear renders red on HW
M3 display a rendered BO (sprite/OS_SpriteOp) DONE
M4 libdrm→SWI shim for a ported Mesa DONE (shim/); Mesa port TODO
M5 EGL platform: Wimp window <→ V3D BO DONE (egl/)
—> the V3D GPU now renders end-to-end on Pi4/CM4 (M0-M5 all verified).
Whats Next: Real IRQ handler, GMP, OOM overflow, multi-core, perfmon,
free-BO SWI (needed by the shim’s GEM_CLOSE),
Wimp-redraw present + double buffering, the Mesa port itself
This driver targets the Raspberry Pi 4 and Compute Module 4 only
Its currently in the stages of Implementing MESA And OpenGL, Eventually WebGL